There are already many questions similar to this but all the ones I could find have answers that suggest polling methods (1, 2) or seem like extreme hacks (3), so I want to ask the same question but with the added caveat that solutions must not use polling:

What I'm looking for is some kind of API that is commonly available (or easily installable) on Linux desktop systems that lets you listen for these two events:

  1. The user has been "idle" (not moving the mouse, typing on the keyboard, etc.) for N seconds (where you can specify N).
  2. After (1) had previously been triggered (and only then!), the user has now performed some activity and should no longer be considered idle. After this event, (1) can be re-triggered, allowing the cycle to repeat.

For (1), it is not very important to me that it happens without polling, as in my use case, the tolerance for delays when reacting to this first type of event is high enough that I'm fine with polling every 10 seconds. But for event (2), the reaction should feel instant, so with polling approaches, I'd have to poll every 0.1 seconds or so, which would be an unacceptable waste of CPU time.1

So I'd consider (1) "solved" by the suggestion to use use something like xprintidle in a polling fashion, but as the definition of (2) relies on (1), I felt it should be listed here anyway.

Any ideas for APIs that implement (2)? How do screensavers etc. do it?

1 To understand the motivation here, compare how you would feel if e.g. dpms turned off your screen after 10 minutes and 10 seconds rather than the 10 minutes you configured vs how you would feel if there was a 10 second delay to turning it on again after detecting activity... It seems to me like most use cases imply a greater tolerance for "idle detection" than for "un-idle detection".

  • "Screensavers" are open source. Download the source for a screensaver, read the source, and see how they do it. Read man apt-get`
    – waltinator
    Commented Dec 25, 2021 at 23:17
  • @waltinator That's what I've been doing, just figured I'd ask before I waste my time on something someone else has already done. Anyway, I was able to trace the origin of "screen saver off"-events in the X Screen Saver Extension back to these lines in the input processing. So unless I'm mistaken, X itself doesn't do anything much more sophisticated than the xinput-based solution I linked in my question, listening for any input event whatsoever.
    – smheidrich
    Commented Dec 25, 2021 at 23:19
  • So now it's just to find the proper API for non-X-internal code to listen to all events in the same manner and it will be close enough. Although I'm still pretty sure someone else must've done this before me. The problem with looking at other screensavers' code is that many of them just listen for events received by their own all-encompassing window, which is only present while the screensaver is active - not a viable solution to the problem of listening to any activity irrespective of the current window.
    – smheidrich
    Commented Dec 25, 2021 at 23:27


You must log in to answer this question.

Browse other questions tagged .