Proposed additions to ext_idle_notify interface to allow monitoring of user activity

Since #213 didn't get much response, I hope to jumpstart things with a more concrete proposal. I propose three alternatives to revise ext_idle_notify from @emersion:

Alternative 1

There would be a new request, similar to the pre-existing request get_idle_notification, called get_user_idle_notification. This request would have the same arguments as get_idle_notification, but it would create a notification object with a slightly different interface, entitled ext_user_idle_notification_v1 (or should it end in _v2?). This notification object would behave like ext_idle_notification_v1 but with one significant difference -- it would ignore zwp_idle_inhibitor_v1 and similar idle inhibitors. This would mean that this notification object would respond to changes in user activity alone, e.g., keyboard and mouse input, and ignore idle inhibit requests altogether.

Power management apps should be unaffected by this, since they'd just use the original get_idle_notification and ext_idle_notification_v1. However, Wayland apps that are meant to monitor user activity in particular would use get_user_idle_notification and ext_user_idle_notification_v1 instead.

Alternative 2

The ext_idle_notification_v1 would have two new events associated with it:

• user_idled(): This event would be sent if no user activity has happened for at least the timeout duration, regardless of whether an zwp_idle_inhibitor_v1 or similar idle inhibitor has been created.
• user_resumed(): This event would be sent if user activity has resumed, again regardless of whether an zwp_idle_inhibitor_v1 or similar idle inhibitor has been created.

It would be an error to send user_idled() twice without a user_resumed() event in between, and similarly, it would be an error to send user_resumed() twice without a user_idled() event in between. There is no requirement for these events to be ordered in any particular way with respect to the pre-existing idled() and resumed() events.

Power management apps should be unaffected by this, since they'd just use the idled() and resumed() events, which would mean the same thing as they do currently. However, Wayland apps that are meant to monitor user activity in particular would use the user_idled() and user_resumed() events instead.

Alternative 3

There would be a new request, similar to the pre-existing request get_idle_notification, which for now I'll call get_idle_notification_alt for lack of a better name at the moment. This request would have the same arguments as get_idle_notification, but it would create a notification object with a slightly different interface, for now entitled ext_idle_notification_alt_v1 (should it end in _v2?). This notification object would behave almost like ext_idle_notification_v1, but it would have four events associated with it:

• idled(): This event would be sent if no user activity has happened for at least the timeout duration, regardless of whether an zwp_idle_inhibitor_v1 or similar idle inhibitor has been created.
• resumed(): This event would be sent if user activity has resumed, again regardless of whether an zwp_idle_inhibitor_v1 or similar idle inhibitor has been created.
• inhibit_start(): This event would be sent when idle inhibition is active.
• inhibit_end(): This event would be created when idle inhibition has been deactivated.

It would be an error to send idled() twice without a resumed() event in between, and similarly, it would be an error to send resumed() twice without an idled() event in between. It might also be an error to send inhibit_start() twice without an inhibit_end() event in between, or to send inhibit_end() twice without an inhibit_start() event in between, but that could also be an unnecessary complication to the implementation.

Wayland apps that are meant to monitor user activity alone would use get_idle_notification_alt and ext_idle_notification_alt_v1 and ignore the inhibited() event, which would likely be irrelevant to them.

Power management apps could either just use the original get_idle_notification and ext_idle_notification_v1 as they do already, or they could instead use ext_idle_notification_alt_v1 and take into account idle inhibition by not triggering a timeout if they detect an inhibit_start() event, much as apps like swayidle and hypridle already avoid triggering a timeout if they detect an idle inhibition event from a D-Bus interface.

I'm not sure which of these alternatives would be better. The first two alternatives have similar semantics, and the choice of one or the other would likely depend on which would be easier to implement. The third alternative provides a path to eventually deprecating the ext_idle_notification_v1 object in favor of ext_idle_notification_alt_v1 (which arguably has a more elegant approach because it simplifies the behaviors of the idled() and resumed() events).

Judging from what I've read of the wlroots implementation of ext-idle-notify, it looks like alternatives 1 and 3 would be the most straightforward to implement. In alternative 1, the counterpart to the wlr_idle_notifier_v1_set_inhibited() would be a no-op, while in alternative 3, the counterpart to the wlr_idle_notifier_v1_set_inhibited() would send events rather than reset notification timers.

If you have any other ideas, whether they be better names or more substantive suggestions, great.

Ultimately, what I want is to have RSI (repetitive stress injury) monitoring apps in Wayland that aren't essentially broken because they use a protocol that almost but not quite does what they need.