We should revisit how idle-notify and idle-inhibit interact, esp. w. respect to RSI

In the discussion on the merge request for the idle-notify protocol, Simon Ser wrote ( !29 (comment 1554554)):

I've decided to restrict the protocol to a single use-case for now: power management daemons. It's the only thing KDE's idle protocol used for right now. We can always extend the protocol later on if it turns out to be a good idea.

This was after David Edmunson pointed out that the author of RSI Break -- a utility that monitors user activity in order to enforce typing breaks -- complained that the "idle-inhibtor behaviour inteferes with" it. ( !29 (comment 560996)).

The problem is that in practice, the idle-notify protocol already isn't limited to the "single-use case" of power management. If anything, its use outside of that use case has expanded. Multiple typing break monitors for RSI on Wayland use the idle-notify protocol to monitor user activity. In addition to RSI Break, there's Workrave, which uses the protocol for non-GNOME compositors, and SafeEyes, which indirectly uses the protocol via its use of swayidle. A big reason for this is simply that the idle-notify protocol, as imperfect as it is for the purpose of monitoring user activity, is really the only game in town for a typing break monitor that can work across multiple Wayland compositor implementations.

Another problem is that while RSI typing break monitors are a niche use case, they are useful for those trying to keep their RSI in check, and neglecting those users would arguably be, as the progressive kids would say these days, ableist and not inclusive.

As for what should be done about this, I start with an observation on how swayidle and hypridle already behave. In addition to using the idle-notify protocol to check how long a user has been inactive, they also listen for D-Bus idle inhibit events. (See https://github.com/swaywm/swayidle/issues/38 for the case of swayidle, and https://wiki.hyprland.org/Hypr-Ecosystem/hypridle/ for the case of hypridle.)

If the Wayland idle-inhibit protocol isn't being used, then on systems that have working D-Bus idle inhibit implementations, you effectively have a situation where the idle-notify protocol indicates whether the user is not idle, while the D-Bus idle inhibit system handles cases where the computer is not idle, e.g., because Firefox is showing a YouTube video. In my experience using Workrave on KDE-Wayland and several other Wayland compositors, this works out nicely: I can watch a video without Workrave bothering me with unnecessary breaks, while still getting the benefit of Workrave for when I am actually active.

So what would I suggest? As someone who is mostly an end user but has contributed pull requests here and there, I want to be careful and not ask for the moon. However, based on what has already been going on in the Wayland ecosystem, I think the following would be a useful approach:

• Let the idle-notify protocol be responsible for monitoring user idle status -- that is, whether the user is providing keyboard or mouse movement -- and user idle status only. Idle inhibition for power management and screen locking purposes would be entirely out of its scope.
• Replace the current Wayland idle-inhibition protocol with one where a Wayland client tells the compositor that it requests that there be no screen locking, monitor blanking, suspending, etc.; and another Wayland client can query the compositor as to whether such a request has been posted. (This is deliberately modeled on what the D-Bus-based idle inhibition system seems to do.)

Power management clients like swayidle can query the compositor to see if a client has requested that screen locking, monitor blanking, suspending, etc. be blocked, and respond accordingly. This would not be far off from what they are already doing with D-Bus idle inhibition events. RSI apps and other applications for monitoring user activity can stick to using the idle-notify protocol as they already do, but with the guarantee that idle inhibition would not impair them.

I think this approach would work codify much of existing de facto practice and not deviate too much from the status quo. Most of the recommended changes would be to a protocol that is already unstable. (Indeed, if the current Wayland idle-inhibit protocol is simply deprecated, no changes would be required to the idle-notify protocol.)

Any thoughts on this?