Configurable idle-inhibit behavior in the idle service

[moedesux]

Suggestion: configurable idle-inhibit behavior in the idle service

Summary: Add a config option so omarchy's idle service can decide how to handle clients that hold Wayland idle-inhibit requests — giving users a lever to keep the screensaver firing during a long download, without changing any defaults.

Why this fits omarchy's design

omarchy's identity is a beautiful, modern, opinionated Arch with Hyprland, and the idle service's respectInhibitors: true is a deliberate opinionated default: it honors the Wayland idle-inhibit protocol, which is exactly right for the common case (video playback should suppress the screensaver). This suggestion keeps that as the default and only asks for a configurable escape hatch.

The underlying issue is that the protocol is binary — a client either inhibits or it doesn't — and omarchy currently gives users no lever over it. A download and a video are indistinguishable at the compositor level, yet users reasonably want different outcomes. That tension is precisely where a configurable default belongs.

This is a natural extension of the existing idle.screensaver / idle.lock surface: the idle service already reads user config from ~/.config/omarchy/shell.json, so the change slots into an established pattern rather than introducing a new mechanism. It's low-risk — purely additive keys, defaults unchanged, no behavior change for anyone who doesn't opt in — and it complements the direction visible in related issues, which show the idle service being actively reworked.

The concrete problem

Chromium/Brave holds a Wayland idle inhibitor while a download is in progress (its Power Save Blocker, active on the downloads page). So during a long download the screensaver never fires, even though the user is sitting idle. Most people expect the screensaver to still appear, and ideally for the machine not to lock or blank until the download finishes.

Why it can't be fixed elsewhere

• No Hyprland window rule can override it. The idleinhibit none rule is purely additive and cannot remove an inhibitor a client holds. (Verified against Hyprland 0.56.2 source.)
• Chromium has no user-facing flag to disable download power-save blocking (open upstream request: issues.chromium.org/issues/41440883).

That leaves omarchy's idle service as the only sensible place for a fix.

Proposed change — worked config

{
  "idle": {
    "screensaver": 180,
    "lock": 900,
    "respectInhibitors": true,
    "screensaverDuringInhibit": false
  }
}

• respectInhibitors (default true, preserving current behavior). Set to false to fire the screensaver and lock on input-idle regardless of any inhibitor. Quickshell's IdleMonitor supports respectInhibitors: false, which uses the ext-idle-notify-v1 v2 input-only notification, so this is straightforward.
• screensaverDuringInhibit (default false) — the "stuck-inhibitor" mode. Keep respecting inhibitors normally, but add a second input-only monitor. If input has been idle past the screensaver timeout while an inhibitor is what's blocking the cycle, fire the screensaver but skip the lock and display-off timers. A download can finish with the screensaver showing, without the machine locking or blanking.

How the stuck-inhibitor mode works

The service already instantiates one Quickshell IdleMonitor { respectInhibitors: true }. Quickshell supports multiple coexisting IdleMonitor instances, each with its own respectInhibitors value:

1. Add a second monitor with respectInhibitors: false. This issues the v2 get_input_idle_notification request, which reports idle based purely on input activity, ignoring all inhibitors.
2. When the input-only monitor reports idle past the screensaver timeout but the inhibitor-respecting monitor does not (i.e., an inhibitor is blocking the cycle), fire the screensaver only — leave the lock and display-off timers untouched.
3. Optionally include a short grace period to avoid flicker if the inhibitor is released mid-cycle.

This preserves video behavior: while watching video, input is also idle, but the inhibitor is "legitimate" — the mode only affects the screensaver, never the lock, and the user can tune or disable it. To be honest about the inherent trade-off: input-only idle during video would still fire the screensaver in this mode, since downloads and playback are indistinguishable at the compositor level. That's exactly why the simpler respectInhibitors boolean remains available as the alternative.

I'll leave the exact defaults and shape to your judgment on what fits omarchy's opinionated design. Thanks for considering it!

References

• Chromium 146 prevents display sleep via Wayland idle inhibit #5092 — "Chromium 146 prevents display sleep via Wayland idle inhibit" (related but distinct: a Chromium regression on normal pages). Its suggested windowrulev2 = idleinhibit none, class:^(chromium)$ workaround does not work, because Hyprland window rules cannot override a client-held inhibitor.
• Re-implement D-Bus idle-inhibit support dropped in the Quattro rewrite #6572 — "Re-implement D-Bus idle-inhibit support dropped in…" (shows the idle service is actively maintained).
• issues.chromium.org/issues/41440883 — upstream Chromium request to disable download power-save blocking.