Steam idle-inhibit rule matches the client but not steam_app games

[nicoladen05]

System details

AMD Ryzen 7 7800X3D, NVIDIA RTX 4070, Omarchy 4.0.0-1, Hyprland 0.56.2

What's wrong?

The default Steam window rule combines floating the Steam client with inhibiting idle while fullscreen:

o.window("steam", { float = true, idle_inhibit = "fullscreen" })

Source: https://github.com/basecamp/omarchy/blob/9b72edcc94513cba016f145b1ac4ffdaea54b577/default/hypr/apps/steam.lua#L1

Because Hyprland class regexes are full matches, this rule applies to the Steam client class steam, but not games launched by Steam, whose XWayland class is normally steam_app_<appid>. The float = true effect also suggests this rule was primarily intended for the Steam client. Conversely, idle_inhibit = "fullscreen" is most useful on the game windows.

For example, while Assetto Corsa was running fullscreen, hyprctl clients -j reported:

{
  "class": "steam_app_244210",
  "title": "Assetto Corsa",
  "fullscreen": 2,
  "xwayland": true,
  "inhibitingIdle": false
}

After the configured idle timeout, the Omarchy screensaver opened over the game. Controller input does not reliably reset the compositor's idle timer, so the missing inhibitor becomes visible during controller-only play.

The next Steam rule already uses steam.* to cover both client and game classes for opacity:

o.window("steam.*", { tag = "-default-opacity", opacity = "1 1" })

Steps to reproduce

1. Enable Omarchy idle handling and use a short screensaver timeout.
2. Launch a Steam/Proton game whose class is steam_app_<appid>.
3. Run the game fullscreen and use only a controller.
4. Check hyprctl clients -j; the game reports inhibitingIdle: false.
5. Wait for the idle timeout; the screensaver launches over the game.

Expected

Fullscreen Steam game windows should inhibit the Omarchy screensaver and lock timer. The Steam client can retain its existing floating behavior.

One possible approach is to split the concerns:

o.window("steam", { float = true })
o.window("steam_app_.*", { idle_inhibit = "fullscreen" })

Alternatively, the existing steam.* match could receive the fullscreen inhibitor if Steam Big Picture should also inhibit idle.

Related reports

• Screensaver activates while running games #1269 originally reported the screensaver activating during controller gameplay and was closed by Set hypridle exception for fullscreen apps #1303.
• Screen saver activates while gaming - lutris, etc #5093 reported the same symptom for other game launchers.
• Treat gamepad input as Quickshell idle activity #6352 attempted to treat gamepad input as activity; the maintainer response preferred marking gaming applications as idle inhibitors.
• [Quattro] D-Bus idle inhibits are silently dropped since hypridle was replaced — screensaver fires during video playback (reproduced with Zen browser) #6475 / Re-implement D-Bus idle-inhibit support dropped in the Quattro rewrite #6572 concern missing D-Bus inhibitor support in Quattro. This issue is narrower: the explicit Hyprland Steam rule does not match steam_app_* windows, and the live client reports inhibitingIdle: false.

[VillainRU]

Confirmed independently on Omarchy 4.0.0-1 with a Sony DualSense controller. During controller-only gameplay, gamepad input does not reset the idle timer. After the configured 15-minute timeout, the PC locks and the displays turn off despite active gameplay. The same behavior occurs when the controller is connected via USB cable, so using a wired connection does not change the situation. Mouse or keyboard activity prevents this as expected.

[VillainRU]

Confirmed that the proposed workaround fixes the issue on Omarchy 4.0.0-1 with Hyprland 0.56.2:

o.window("steam_app_.*", { idle_inhibit = "fullscreen" })

I added it to ~/.config/hypr/hyprland.lua and reloaded Hyprland. hyprctl configerrors is clean, and a fullscreen steam_app_* window reports:

fullscreen: 2
inhibitingIdle: true

I also tested controller-only gameplay with a Sony DualSense for longer than the configured idle timeout. Neither the screensaver nor the lock screen activated. Normal idle locking resumes after leaving fullscreen or closing the game.

[JakePi3]

Not all steam games set their window class to steam_app_<steamid> as seen from hyprctl clients so this is not a complete fix.

[cinco]

Another window class that misses this rule: gamescope.

Games launched through gamescope (gamescope -- %command% in the Steam launch
options) never expose a steam_app_<appid> class. The window Hyprland sees is
gamescope's own, and it is a native Wayland window, not XWayland:

class:          gamescope
initialClass:   gamescope
title:          Rocket League (64-bit, DX11, Cooked)
fullscreen:     2
xwayland:       false
inhibitingIdle: false

So neither o.window("steam", ...) nor the proposed o.window("steam_app_.*", ...)
matches, which is the incomplete-fix case @JakePi3 mentions above.

Reproduced on Omarchy 4.0.0-1 with a GameSir Cyclone 2, idle.screensaver = 150.
The shell's idle service logged the screensaver launching twice during a match:

idle-monitor: idle
idle-cycle-start: screensaver=150 lock=300
process-start: screensaver [...] omarchy-launch-screensaver

Adding this to ~/.config/hypr/hyprland.lua fixes it; hyprctl configerrors is
clean and the live window flips to inhibitingIdle: true on reload:

o.window("gamescope", { idle_inhibit = "fullscreen" })

A complete default would need to cover the gamescope class alongside
steam_app_.*, since gamescope is the common way to run Steam games fullscreen
on Hyprland.

[JakePi3]

I believe steam_app_.* matches all Proton games, but the game I was testing had a native Linux client. Of course there are other wrappers other than gamescope that could be in play (such as mangohud). Additionally games launched through lutris and heroic may also have special rules.

[etherealheim]

Happening to me with Steam Controller as well. Using:

For borderless/windowed fullscreen, this user-level workaround is likely best:

  -- ~/.config/hypr/hyprland.lua
  o.window("steam_app_.*", { idle_inhibit = "focus" })

For now.

[ACooperDev]

Adding a concrete case for this comment, since it turns out to matter for the proposed fix:

Not all steam games set their window class to steam_app_ as seen from hyprctl clients so this is not a complete fix.

Age of Empires II: DE (appid 813780), Proton Experimental, reports class steam — the same class as the client, not steam_app_813780. From hyprctl clients -j while the game was running fullscreen-capable:

{
  "class": "steam",
  "title": "Age of Empires II: Definitive Edition",
  "xwayland": true,
  "floating": true,
  "fullscreen": 0,
  "size": [842, 601]
}

Two consequences for this issue:

1. steam_app_.* would not fix this machine. The workaround confirmed above (o.window("steam_app_.*", { idle_inhibit = "fullscreen" })) never matches this game, so it still gets no inhibitor. Any fix that keys on steam_app_ will silently miss whatever subset of Proton titles land on class steam.

2. The float = true half of the rule is actively harmful where it does match. Because this game matches "steam" exactly, it inherits float = true and comes up as an 842x601 floating window in the middle of the screen, visibly flickering — the game repeatedly tries to go fullscreen and the rule pulls it back. It's unplayable until overridden. That's the inverse of the problem reported here: the rule failing to reach games is one half, and reaching a game it shouldn't is the other, and both come from the same unqualified matcher on line 1.

The rules immediately below it are already title-qualified, which is what makes the first line stand out:

o.window("steam", { float = true, idle_inhibit = "fullscreen" })   -- no title qualifier
o.window({ class = "steam", title = "Steam" }, { center = true, size = { 1100, 700 } })
o.window({ class = "steam", title = "Friends List" }, { size = { 460, 800 } })

Splitting the two effects would address both directions: qualify float to the actual client windows by title, and apply idle_inhibit by something that catches games regardless of which class they land on.

What I'm using locally as a per-game override:

o.window({ class = "^steam$", title = "^Age of Empires II" }, {
  tile = true, fullscreen = true, idle_inhibit = "fullscreen",
})

Worth noting for anyone debugging this: the class is easy to guess wrong. I wrote my first rule against steam_app_813780 on the assumption in this thread, and it silently matched nothing. hyprctl clients -j while the game is actually running is the only reliable check.

System details

Intel Core i9-10885H, Intel UHD 630 + Quadro RTX 5000 Mobile (hybrid), Omarchy 4.0.3-1, Hyprland 0.56.2, kernel 7.2.3-arch1-3.

[masegraye]

idle_inhibit = "fullscreen" is not enough. Many games run borderless, not fullscreen.

Tested today on Omarchy 4.x, Hyprland 0.56.2. The game window is a steam_app_* class. It runs borderless. Hyprland does not report it as fullscreen:

$ hyprctl clients -j | jq '.[] | select(.class|startswith("steam_app")) | {fullscreen, inhibitingIdle}'
{ "fullscreen": 0, "inhibitingIdle": false }

The fix in this issue and in #7334, #9667, #10447, #11083, #11272, #11981 is:

o.window("steam_app_.*", { idle_inhibit = "fullscreen" })

That rule never matches this window. The screensaver and lock still fire during play. Borderless is the default display mode in many Unity and Unreal games, and Proton often produces it.

Use focus instead:

o.window("^steam_app_.*", { idle_inhibit = "focus" })

Result after hyprctl reload (no configerrors):

game focused:          inhibitingIdle: true
terminal focused:      inhibitingIdle: false

focus covers fullscreen and borderless. It releases when you switch away from the game, so a game left in the background does not block the lock.

Recommend that whichever PR lands uses focus, not fullscreen.