The Problem
Several applications need to know about user activity. This includes screen savers, RSI prevention tools like Workrave, and IM programs (for automatic away message). Currently each program has to implement activity tracking itself. This means that there is no unified configuration, but also that programs like movie players have to resort to hacks to prevent screen savers from activating. It’s also not possible for users to trigger a generic “away” event that causes the screen to be locked, the IM program to set the away status etc. pp.
A unified system would have the following requirements:
- There needs to be an idle time, after which screensavers could active. for example.
- There needs to an away time, after which the user is considered to be AFK. This could trigger screen locking, and IM status changes.
- Programs must have the ability to signal user activity, so that screen savers won’t activate while watching a movie.
- Programs must have the ability to temporarily shut the activity listening off. This is needed by xlock-like programs, where the program itself is the only authority to reenable user activity.
The Proposal
A central daemon (yay, another daemon!) communicates with other program via d-bus. This daemon listens for user activity, i.e. mouse movement and key presses. Basically there are four user states:
- busy
- The user is currently using the computer.
- lazy
- The user hasn’t used the computer for a set amount of time.
- away
- The user is away from the keyboard.
- locked
- Like “away”, only that wakeup events are ignored until the
mode is manually changed.
In general the possible mode changes are busy → lazy, busy → away, busy → locked, lazy → busy, lazy → away, lazy → locked, away → busy, away → locked, and locked → busy.
The following messages are sent by the daemon:
- idle
- This specifies are reason for the status change as parameter,
for example “timeout:600”, meaning that there was no user activity
for 600 seconds. This message may be repeated with reason “repeat”. - away
- This message is sent when the user is away. It also includes
the reason, for example “timeout:1200” or “userrequest”. It may
also be repeated. - busy
- This message is sent when the user returns to work. It has
an optional reason parameter, and may be repeated.
The daemon understands the following messages:
- activity-ping
- This is sent by some applications, like movie viewers every
few seconds to signal that the user is busy, although there is
no user activity. - gone-away
- This is sent by applications when the user explicitly toggles
the away status, for example by selecting “lock screen” from the
system menu. - locked
- Similar to gone-away, only that auto-wakeup is disabled. The only
entity to reenable listing to events is the sender of the locked
message. Therefore a detail string must be passed. This is used by
xlock-like applications to prevent applications from changing the
“away” status, just because someone moved the mouse. - unlocked
- The corresponding unlock signal to the locked message. Must use
the same detail string.
Use Cases
- Screen Saver
- When the screen saver receives the away signal, it
turns on the screen saving (if it’s not already running). If it
receives the busy signal, it turns of the screen saver. It ignores
the other signals. - Away Button
- When a user uses a potential away button in the system menu,
the menu sends the “gone-away” message to the daemon. - Screen Lock
- When a user uses the “Lock Screen” button in the system
menu, the menu sends the “locked” signal to the daemon. It starts
the screen saver and listens to user input. When the correct
password has been entered, it sends the “unlocked” signal and
ends the screen saver mode. - Screen Saver with Locking
- When the screen saver receives the away signal, it starts
screen saving, and sends the “locked” signal to the daemon. When
there is user input and the correct password is entered, it sends
the “unlocked” signal. - Instant Messengers
- When the IM program receives the “away” signal, it turns
on the auto-responser and possibly the away method. The
auto-responder message may be modified according to the reason
detail parameter. When the IM program receives the busy signal,
it turns auto-responding and away status off.
To Do
- The current proposal does not address RSI prevention programs like Workrave.
- Security implications of the locked mode.
- The disparity in screen saver responsibilities between normal screen saver activation and xlock activation.