Comment 61 for bug 595555

Re: Comment #47
Chris,
> ... and in the same tick some input events are generated, so
> idle_counter never goes above 60000

Will you believe me if I claim I can generate the input event
(keyboard or mouse), on the same tick (within 1 msec time window) when
idle_counter=60000, with >90% probability in F13 and 4% in F14? I
don't believe such claim; for humans (me included), <0.01% maybe,
definitely not 4% or 90% or 2 out of 3 times.

Here is what I think we overlooked.
  - when determining to trigger an alarm or not, sync.c uses previous
    counter value and new counter value to compare with test_value.

  - This (using previous counter value) is adequate for non-system
    counter, because such counter value change must go through
    SyncChangeCounter(), ie. pCounter->value does not change on its
    own.

  - Unfortunately for idle_counter, the *apparent* value does change
    as time goes by, without invoking SyncChangeCounter(). Why?
    Because idle_counter value is defined as
        idle = GetTimeInMillis() - lastDeviceEventTime.milliseconds;
        /* ie. idle = now - lastEventTime; */
    which changes on its own (GetTimeInMillis() returns different
    value for each milli sec).

  - in view of the above, for idle_counter, we should save
    lastDeviceEventTime.milliseconds in some local variable, eg.
    prevLastDeviceEventTime. When oldval is needed, instead of
        oldval = pCounter->value;
        /* adequate only for non-system counters */
    we should use
        oldval = GetTimeInMillis() - prevLastDeviceEventTime;
        /* for idle_counter */
    so the current idle_counter value is properly updated.

With this change, the different definitions in Comment #38 become
largely irrevelant: they occur only on rare occasions.