The Gamepad/Joystick Screensaver Bug was reported ages ago to Canonical.
See https://bugs.launchpad.net/ubuntu/+source/gnome-screensaver/+bug/30378
The outcome of the bug report was, that the application that uses the Joystick is responsible for deactivating the screen saver.

So it would be nice if the Steam Client deactivates the screen saver in the moment before a game is started and reactivates it after the game exited.

Disabling the screensaver, however, is not a trivial thing. there is no "one-way" to disable the screensaver. Well actually there is libXss aka XscreenSaver. However it seems noscreensaver applications use that library at all. And instead to suspend the screensaver the game/video player/etc.. must repeatedly spawn the screensaver application to request it to "don't start". which is hideous and error prone.. (especially if the user doesn't have THAT screensaver on their system). Not to mention that there are Many screensaver applications that do this.. (ones I know of are gnome-screensaver, xscreensaver, KDE(though it looks like they are ditching it?). Each with their own method of disabling the screensaver and no single unified way of doing it..

After some discussions with Ryan Gordon, and a little more research, I finally did find a semi-acceptable solution.

http://portland.freedesktop.org/xdg-utils-1.0/xdg-screensaver.html

this (*lengthy) script file does all the voodoo needed of detecting and calling into the various screensaver applications (of which there are Much more than I had originally thought).

It's at least a step. I shall see what I can do to getting this fixed up in bastion in the coming weeks.

I have been using a modified version of "https://github.com/hotice/lightsOn" to keep the screen on. But would love to see this issue fixed.

Forgot to use caffeine or lightsOn and noticed that steam in Big Picture mode is also affected by this bug. :/

Hammerwatch has the same problem. I imagine that anything that exclusively uses the controller could be affected, but I notice that Mark of The Ninja does NOT suffer from this bug.

so while I don't know about screensavers, at least the screen dims and/or turns off feature has a more or less "obvious" way of turning off.

so apparently software can now go for a more straight power management override,

sorry @PyGuy95 but personally I think for native linux games, those should be going and sending those signals as they know best when to use them while a steam-global way of doing this cant account for everything and may be too broad.

a game for example could be sending those signals while recieving input, but when nothing is happening still lay the computer idle during "gameplay sections" but when you have like a movie inside the game where the user just watches and isnt supposed to do much inputs it can send a constant override during that time, similar to vivaldi only stopping power management in certain scenarios like for example actively playing audio in a youtube video.

but for the big picture interface this issue certainly has merit.

a game for example could be sending those signals while recieving input

Input should suspend screensavers and some energy saving features by default, no need for the application (game) to send any signals.
This already is handled fine for keyboard and mouse but not for controllers which are user input.

In the case of cut scenes and sections without user input like the example from Vivaldi (awesome browser, btw) where an audio and probably video is playing then this is the application's job and it should warn the system that no commands from the user are expected.

An argument can be made about games blocking screensavers from start to finish but screensavers should just respect controller input in the same way as keyboard and mouse input.

I don't remember seeing this problem in a long time, i'll check if it still exists here. :)

I agree that controller input should also be handled as activity, but apparently it isnt always, I had this a few times which is especially noticable on laptops because they usually dim the screen relatively quickly.

but regarding why gamepads dont affect energy management, while I dont know the reason I am fairly sure there has to be SOME reason, after at least windows and linux are and/or were affected. maybe (just me theorizing) the system doesnt see that the joystick currently matters or whatever similarly as if when you are in a console-only mode on the OS, I doubt it'll care much about mouse input, similar to that would be the joystick situation.

I recently had the issue while playing Yugioh in Proton, and went talking about it there and this issue was noted as possibly related.

@kisak-valve it still happens to this day, Steam controller + Sekiro + intense boss fight is not considered as activity from the system, therefore Steam should send some command (dbus or something) to keep the system awoken.
For users, install caffeine as a workaround.

I confirm it happens with weird xbox 360 controller as well.

This is also happening with Steam Controller in The Witcher III on KDE Plasma (5.16.80 / 5.17 beta).

I can observe this too, albeit with a different game. Has anybody filed an upstream bug with GNOME or KDE about this?

I can observe this too, albeit with a different game. Has anybody filed an upstream bug with GNOME or KDE about this?

You mean the issue is specific to desktop environments? I thought it was something with the support of the game itself. Obviously not to a specific game but something regarding the games that are affected by this. Now I wish I could test that theory by switching my KDE to something like i3 unfortunately plasma doesn't allow you to do that.

I especially thought it was regarding something specific to the wine/proton support of the game since the issue doesn't occur on elder scrolls online but does in skyrim special edition.

https://bugs.kde.org/show_bug.cgi?id=328987

Why wouldnt Steam just set systemd-inhibit when running a game - just as its doing and preventing screensaver/computer sleep when idlying without a game running? At the end of the day, nowadays almost any desktop linux distro is using systemd and so is steam - just its inhibit behaviour is literally an opposite of what its supposed to be? https://github.com/ValveSoftware/steam-for-linux/issues/5607

@Dinth FYI, there is a d-bus API to inhibit screen savers on many desktops. If the goal is only to support some systems, that can be accomplished without making Steam require systemd, which would break things for some people.

IMHO, the correct solution would be for game controllers to be recognized as input devices in the same places where keyboards and mice already are: the display servers. Of course, that's not Valve's code (except maybe on the Steam Deck).

Until that happens, we're stuck with workarounds at higher levels. It's probably reasonable for Steam to implement one, but let's keep in mind that Steam also has to maintain compatibility with a variety of different environments, including containers.

Anyone struggling with this issue might want to have a look at joystickwake or gamemode.

Anyone struggling with this issue might want to have a look at joystickwake or gamemode.

Gamemode does fix the issue, but it requires modifying command line option with every single game

FYI, there is a d-bus API to inhibit screen savers on many desktop

All right, but this is a detail how to inhibit the screensaver/sleep. The fact is that Steam already does that, but only when a game is NOT running, and turns inhibit off when the user actually runs a game.

IMHO, the correct solution would be for game controllers to be recognized as input devices in the same places where keyboards and mice

That would be nice indeed, but regardless, when a game is running Steam should inhibit sleep anyway.

let's keep in mind that Steam also has to maintain compatibility with a variety of different environments,

Again, regardless whats the actual technical solution of implementing inhibit - Steam already implements it. Just in wrong times.

All right, but this is a detail how to inhibit the screensaver/sleep.

Well, sure, but I was replying to your prescription of systemd, which is also an implementation detail, and one that would break things for some of us.

but regardless, when a game is running Steam should inhibit sleep anyway.

Not necessarily, since it would defeat the purpose of a screen saver: When people walk away from the computer or fall asleep, it would needlessly waste power, drain laptop batteries, and push OLED screens toward burn-in. It would probably make sense as an option, though, for folks who don't want to disable their screen savers entirely. FWIW, you can already do this with GameMode.

The fact is that Steam already does that, but only when a game is NOT running, and turns inhibit off when the user actually runs a game.

That's curious. I just tested this (Slay the Spire native Linux version, Steam Flatpak, KDE Plasma 5, Xorg). I could still see the "Steam is currently blocking sleep and screen locking" message in my power management panel while the game was running, but it periodically went away, and then came back every so often. I wonder if Steam is inhibiting in reaction to mouse input while the game is running.

Anyone struggling with this issue might want to have a look at joystickwake or gamemode.

Gamemode does fix the issue, but it requires modifying command line option with every single game

Or you could use gamemoderun in the command line you use to launch Steam itself, rather than each game.

I also mentioned joystickwake, which doesn't require modifying app launch options. Did you miss that? (Note: its dbus inhibitor persists for a limited-but-configurable time after controller activity stops; see my comment about laptops and OLED screens.)

Why wouldnt Steam just set systemd-inhibit when running a game - just as its doing and preventing screensaver/computer sleep when idlying without a game running? At the end of the day, nowadays almost any desktop linux distro is using systemd and so is steam - just its inhibit behaviour is literally an opposite of what its supposed to be? #5607

because that would just be what we in germany call the "wood hammer method", way too simple of an approach and can cause its own issues, the screensaver should trigger even if the game is running, especially on oled screens.

the problem is that controller input does not contribute to "input" in terms of screensaver stuff

regarding the "blocking sleep and screenlocking" yes that's exactly what it does, apparently there are multiple inhibit methods or settings or whatever, some only block sleep and stuff (which is great when e.g. steam is downloading stuff as you would want the PC to properly stay on, but the screen to still turn off) and then there's a mode that also blocks screensavers (which e.g. is used by videoplayers etc.

This is likely not an issue any more as Bastion blocks screen locking as is seen in Power Management