Monitor no longer shuts off when idle

[saellaven]

Your system information

• Steam client version (build number or date): August 1, 2018
• Distribution (e.g. Ubuntu): Gentoo
• Opted into Steam client beta?: [Yes/No] No
• Have you checked for system updates?: [Yes/No] Yes

Computer Information:
Manufacturer: Unknown
Model: Unknown
Form Factor: Laptop
No Touch Input Detected

Processor Information:
CPU Vendor: AuthenticAMD
CPU Brand: AMD FX(tm)-8350 Eight-Core Processor
CPU Family: 0x15
CPU Model: 0x2
CPU Stepping: 0x0
CPU Type: 0x0
Speed: 4000 Mhz
8 logical processors
8 physical processors
HyperThreading: Unsupported
FCMOV: Supported
SSE2: Supported
SSE3: Supported
SSSE3: Supported
SSE4a: Supported
SSE41: Supported
SSE42: Supported
AES: Supported
AVX: Supported
CMPXCHG16B: Supported
LAHF/SAHF: Supported
PrefetchW: Unsupported

Operating System Version:
"NAME=Gentoo" (64 bit)
Kernel Name: Linux
Kernel Version: 4.17.10
X Server Vendor: The X.Org Foundation
X Server Release: 11905000
X Window Manager: Metacity (Marco)
Steam Runtime Version: steam-runtime-beta-release_2018-06-14

Video Card:
Driver: NVIDIA Corporation GeForce GTX 1050 Ti/PCIe/SSE2
Driver Version: 4.6.0 NVIDIA 396.45
OpenGL Version: 4.6
Desktop Color Depth: 24 bits per pixel
Monitor Refresh Rate: 59 Hz
VendorID: 0x10de
DeviceID: 0x1c82
Revision Not Detected
Number of Monitors: 1
Number of Video Cards Not Detected
Primary Display Resolution: 1920 x 1200
Desktop Resolution: 1920 x 1200
Primary Display Size: 20.39" x 12.76" (24.02" diag)
51.8cm x 32.4cm (61.0cm diag)
Primary Bus: PCI Express 16x
Primary VRAM: 4096 MB
Supported MSAA Modes: 2x 4x 8x 16x

Sound card:
Audio device: Realtek ALC892

Memory:
RAM: 15918 Mb

Miscellaneous:
UI Language: English
LANG: en_US.UTF-8
Total Hard Disk Space Available: 468427 Mb
Largest Free Hard Disk Block: 20083 Mb
VR Headset: None detected

Recent Failure Reports:

Please describe your issue in as much detail as possible:

Since the update to the version with the new chat features, the monitor no longer shuts off when idle. The screensaver will blank, but the monitor remains on. DPMS is enabled. If I exit steam, the monitor shuts off again when idle.

Steps for reproducing this issue:

[Brottweiler]

Same issue here on Arch Linux. Is it related to

The screensaver will now be correctly interrupted when using controllers or In-Home Streaming

from the July 16, 2018 update?

[saellaven]

It's likely related.

As an added data point, I tried disabling in home streaming and have my steam controller turned off, and the display still won't sleep.

[Muffindrake]

This is still a problem as of today. I'm on a Gentoo machine with a blanking timeout of 10 minutes, which is never triggered as long as Steam is running, but works immediately after Steam is terminated.

[awused]

Confirming this issue on Fedora 28 with Steam version 1536436120. Steam prevents DPMS from turning off my monitors but does not prevent xautolock from locking my screen. I have no controllers connected and I've disabled in-home streaming. If I close Steam DPMS works and my monitors shut off when expected.

If you're trying to reproduce it I've found that if I start Steam but don't interact with it my DPMS settings work as expected, at least with the DPMS timeouts set very low for testing. It's only when I interact with Steam - changing tabs to and from my library, chatting, opening the options menus - that Steam starts interfering with DPMS. It's also possible that letting enough time pass without interacting it will also trigger the bug; I did not test enough to rule this out.

[koniiiik]

FWIW, I've been experiencing this issue since way before the July update, and I remember noticing it even on Windows more than a year ago.

[ortango]

I've been having this issue since at least before issue #5532 opened.

I've got neither org.gnome.ScreenSaver or org.freedesktop.ScreenSaver dbus services and my x11 idle timer continues to increase. Still, my monitors never sleep with steam open (I can just open steam for this issue to take effect, i don't need to interact with it or start a game).

How is steam disrupting dpms behavior as it seems x11 idle isn't used and the dbus methods return errors on my system?

---

for ref. sdl2 functions:

• X11_SuspendScreenSaver()

• SDL_DBus_ScreensaverTickle()

• SDL_DBus_ScreensaverInhibit()

[gogoprog]

I confirm this exact same issue on my system:

Linux 4.x (64 bit)
    Kernel Name:  Linux
    Kernel Version:  4.18.14-arch1-1-ARCH
    X Server Vendor:  The X.Org Foundation
    X Server Release:  12002000
    X Window Manager:  awesome
    Steam Runtime Version:  steam-runtime-beta-release_2018-09-03

[mphe]

I'm still experiencing this problem, too.

Linux 4.x (64 bit)
Kernel Name:  Linux
Kernel Version:  4.18.7-arch1-1-ARCH
X Server Vendor:  The X.Org Foundation
X Server Release:  12001000
X Window Manager:  awesome
Steam Runtime Version:  steam-runtime-beta-release_2018-09-03

[sersorrel]

This is still a problem.

Steam is intentionally inhibiting DPMS. Run dbus-monitor --session, then start Steam, and search the output for "inhibit":

$ dbus-monitor --session
[...]
method call time=1549222988.474789 sender=:1.315 -> destination=org.freedesktop.ScreenSaver serial=2 path=/org/freedesktop/ScreenSaver; interface=org.freedesktop.ScreenSaver; member=Inhibit
   string "My SDL application"
   string "Playing a game"
method call time=1549222988.475227 sender=:1.213 -> destination=org.gnome.SessionManager serial=704 path=/org/gnome/SessionManager; interface=org.gnome.SessionManager; member=Inhibit
   string "My SDL application"
   uint32 0
   string "Playing a game"
   uint32 8

I'm using the Steam client beta, Steam package version 1549129917 (built 2nd Feb 2019 17:21:48).

[gogoprog]

Any news on this?

[ZacJoffe]

Can confirm that this is happening on my Arch install with bspwm as my window manager.

Operating System Version:
    "Arch Linux" (64 bit)
    Kernel Name:  Linux
    Kernel Version:  5.0.3-arch1-1-ARCH
    X Server Vendor:  The X.Org Foundation
    X Server Release:  12004000
    X Window Manager:  bspwm
    Steam Runtime Version:  <Runtime disabled>

[Grinkers]

Can confirm also on
ubuntu 18.10
xfce 4.12

[patlefort]

I can confirm too.
Antergos, Steam beta, KDE.

method call time=1557473218.655330 sender=:1.15 -> destination=org.kde.Solid.PowerManagement.PolicyAgent serial=20651 path=/org/kde/Solid/PowerManagement/PolicyAgent; interface=org.kde.Solid.PowerManagement.PolicyAgent; member=AddInhibition
   uint32 4
   string "My SDL application"
   string "Playing a game"
method call time=1557473218.833311 sender=:1.15 -> destination=org.kde.Solid.PowerManagement.PolicyAgent serial=20654 path=/org/kde/Solid/PowerManagement/PolicyAgent; interface=org.kde.Solid.PowerManagement.PolicyAgent; member=ReleaseInhibition
   uint32 4307

[NotMrFlibble]

Also seeing this here. With the Steam client running, no blanking. Without, blanking occurs as it should.

I'm using the screen blanker built into X, Devuan beowulf, current Steam beta, Xfce, xf86-video-amdgpu 19.0.1.

[bjwest]

Just posting my info from issue #6337 into this thread so people don't have to click though. Also, whether or not I've recently played a game, or played a game since exiting and restarting the Steam client has no bearing on this, it just randomly occurs.

Your system information

Steam client version (build number or date): Jun 21 2019 @ 01:43:20. API v018
Steam package versions: 1561159470
Distribution (e.g. Ubuntu): KDE Neon 5.16
Opted into Steam client beta?: Yes
Have you checked for system updates?: Yes

Please describe your issue in as much detail as possible:

Steam client randomly disables power management with the notification "My SDL application is currently suppressing power management: playing a game" dosplayed in the Battery and Brightness widget. Exiting Steam and restarting will clear the problem for a random period of time, after which the power management is disabled again with the same notification.
Steps for reproducing this issue:

Run Steam client.
Wait a random, indeterminate period of time.
Notice screen no longer blanks after set inactivity time.

Seems to be similar to issue #5532 from about a year ago, but I don't recall having that problem back then. This started happening a few weeks ago, and I've just now taken the time to trace it to the Steam Client.

[gulafaran]

happens here too, and its quite annoying

[mDuo13]

I also have this problem, and have for at least several months. Maybe more; I'm not sure when it started. Monitor never turns off when Steam is running, turns off as normal when idle if Steam is not running.

Operating System Version:
    "Arch Linux" (64 bit)
    Kernel Name:  Linux
    Kernel Version:  5.0.11-arch1-1-ARCH
    X Server Vendor:  The X.Org Foundation
    X Server Release:  12004000
    X Window Manager:  Openbox
    Steam Runtime Version:  steam-runtime_0.20190626.0

[gulafaran]

the really weird part is i dont have a org.freedesktop.ScreenSaver nor org.kde.Solid.PowerManagement.PolicyAgent because i run a standalone WM. and i even tried setting the sdl env vars,
SDL_VIDEO_ALLOW_SCREENSAVER
SDL_HINT_VIDEO_ALLOW_SCREENSAVER

and it still "inhibits" it.

[rdrms]

OS: Fedora 30
Kernel: 5.1.17-300.fc30.x86_64
Desktop: Cinnamon 4.0.10
Steam client version: 1563346602 Built Jul 17 2019 @ 06:14:18

I have an applet (Presentation Applet) that tells when apps are inhibiting the screen saver. Frequently, "My SDL application" will inhibit the screensaver, the only way to get rid of it is to log out or close Steam. Ironically, I also have the opposite problem where Steam wont inhibit the screensaver during a game, and the X server doesn't detect my gamepad as input prolonging the sleep timeout, so in gamepad games the screen will turn after 10 minutes of playing unless I use said applet to disable power saving features temporarily.

[noameyal]

I have the same issue:

Operating System Version:
    "Arch Linux" (64 bit)
    Kernel Name:  Linux
    Kernel Version:  5.2.13-arch1-1-ARCH
    X Server Vendor:  The X.Org Foundation
    X Server Release:  12005000
    X Window Manager:  i3
    Steam Runtime Version:  steam-runtime_0.20190711.3

I'm using the screensaver built in to X too.

[DrDoctor13]

I'm having the same issue.

Operating System Version:
    "Manjaro Linux" (64 bit)
    Kernel Name:  Linux
    Kernel Version:  5.2.14-1-MANJARO
    X Server Vendor:  The X.Org Foundation
    X Server Release:  12005000
    X Window Manager:  KWin
    Steam Runtime Version:  <Runtime disabled>

I initially noticed this due to messages like these appearing in KSyslog:
9/14/19 12:59 PM org_kde_powerdevil powerdevil: Enforcing inhibition from ":1.11" "My SDL application" with cookie 39 and reason "Playing a game"
Then when restarting Steam I would see several of them pop out at once.

|9/15/19 9:42 AM|org_kde_powerdevil|powerdevil: Scheduling inhibition from ":1.11" "My SDL application" with cookie 15 and reason "Playing a game"|
|---|---|---|
|9/15/19 9:42 AM|org_kde_powerdevil|powerdevil: Releasing inhibition with cookie  15|
|9/15/19 9:42 AM|org_kde_powerdevil|powerdevil: It was only scheduled for inhibition but not enforced yet, just discarding it|
|9/15/19 9:42 AM|plasmashell|qml: temp unit: 0|
|9/15/19 9:42 AM|org_kde_powerdevil|powerdevil: Scheduling inhibition from ":1.11" "My SDL application" with cookie 16 and reason "Playing a game"|
|9/15/19 9:42 AM|org_kde_powerdevil|powerdevil: Releasing inhibition with cookie  16|
|9/15/19 9:42 AM|org_kde_powerdevil|powerdevil: It was only scheduled for inhibition but not enforced yet, just discarding it|
|9/15/19 9:42 AM|kdeinit5|Registering ":1.121/org/ayatana/NotificationItem/steam" to system tray|

Xset confirms DPMS is disabled while Steam is running.

Screen Saver:
  prefer blanking:  yes    allow exposures:  yes
  timeout:  0    cycle:  600
DPMS (Energy Star):
  Standby: 0    Suspend: 0    Off: 0
  DPMS is Disabled

While Steam is closed:

Screen Saver:
  prefer blanking:  yes    allow exposures:  yes
  timeout:  0    cycle:  600
DPMS (Energy Star):
  Standby: 120    Suspend: 180    Off: 240
  DPMS is Enabled
  Monitor is On

[NotMrFlibble]

This is exacerbated by #6503 due to repeated unblanking. Previously, once forced, the display would remain blanked (except in specific circumstances).

[tripkin]

I use a hotkey combo running the command sh -c "sleep 1 && xset dpms force off" to force my monitors to sleep - I have sleep mode otherwise turned off. After putting the displays to sleep, the steam client forces them to wake up almost immediately. Sometimes, after putting the monitor to sleep multiple times, the screens will remain dark until either I wake them up or the steam client pops up a message telling me the client is ready to update. This continues until I have exited the client, at which point the screens stay dark until I activate them. Basically, the same as reported above. I did not notice this behavior before I upgraded to Debian Buster from Stretch, but it is definitely a problem now.

Operating System Version:
    Debian GNU/Linux 10 (buster) (64 bit)
    Kernel Name:  Linux
    Kernel Version:  4.19.0-6-amd64
    X Server Vendor:  The X.Org Foundation
    X Server Release:  12004000
    X Window Manager:  GNOME Shell
    Steam Runtime Version:  steam-runtime_0.20191007.0

[bblough]

To add to @tripkin 's comment-
I also have the issue under Buster. However, I definitely had the issue under Stretch as well. Unfortunately I can't recall if I had it under Jessie.

[Ilazki]

I'm also having this problem, currently with Debian Buster, but it's been an issue for years. I always assumed that, since Steam makes heavy use of browser functionality, and I noticed the problem in Chromium around the same time as Steam, that it's related to this bug with Chromium inhibiting power management: https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/1600622

[Zorrototo]

Issue was opened in 2018. Nothing related to Steam Deck.

[ian-h-chamberlain]

It may not be specifically related to Steam Deck, however since the Steam Deck runs Linux it also seems to encounter this problem in desktop mode (I found this issue while looking for solutions to this problem on my Deck)... maybe a little visibility that this impacts Steam Deck / SteamOS users as well will encourage Valve to try and fix it properly with a setting or something?

[Dinth]

Im not sure if this is related, but also Steam inhibits sleep through systemd when steam client is running, but NOT when running a game, which is crazy - my computer is never going to sleep in the night, unless i manually quit Steam, but when im actually playing a game - to does, usually causing the game to crash...

PS. I have compiled the code shared by @InfoTeddy, but cannot make it to work. When im trying to preload it im getting an error regardless if im using lib64 or lib32 version:
ERROR: ld.so: object '/opt/fix_steam_screensaver_lib.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/opt/fix_steam_screensaver_lib64.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
Could someone please advise what am i doing wrong? Here is the wrapper im using:
LD_PRELOAD="/opt/fix_steam_screensaver_lib.so" SDL_VIDEO_ALLOW_SCREENSAVER=1 /usr/games/steam
(i also couldnt get $LIB variable to work)

[ztx-lyghters]

Personally, I do not have systemd on my system, but still having this issue. Though I'm not fully free from the systemd ecosystem, I do at least have elogind installed and running. пт, 7 апр. 2023 г. в 09:34, Michal ***@***.***>:

…

Im not sure if this is related, but also Steam inhibits sleep through systemctl when running, but NOT when running a game, which is crazy - my computer is never going to sleep in the night, unless i manually quit Steam, but when im actually playing a game - to does, usually causing the game to crash — Reply to this email directly, view it on GitHub <#5607 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANNBGGPSPKTDFDQYNJ32HSTW77NRNANCNFSM4FN45DOA> . You are receiving this because you commented.Message ID: ***@***.***>

[G2G2G2G]

steam inhibits sleep/suspend.. period... systemd or not isn't relevant.

[tomaszg7]

steam inhibits sleep/suspend.. period... systemd or not isn't relevant.

Not so simple: sway-idle for example is immune to it.

[G2G2G2G]

yes it is that simple...
you're talking about wayland, in which case it's just broken and thus ironically you get the results you want. anything on X stays awake.

[JakeTheSnake]

I've had this problem for years, and just recently discovered it was gone. Steam Beta Client just received a major rehaul, maybe this is what solved it - intentionally or unintentionally.

Garuda Linux, i3wm

EDIT: Seems like I spoke in haste :( Sleep works if I startup steam without touching it after. But after interacting with it, i.e. playing a game and exiting it, it still blocks sleep.

[G2G2G2G]

Yea the UI overhaul did fix a lot of stuff, not the sleep issue though (on xorg, at least)

[sitedyno]

Not fixed for me ☹️ Just tried the steam beta w/ xorg & i3wm, steam still prevents dpms power saving.

Beta looks good though, much snappier UI 👍

[AaronKelley]

I recently switched to Linux (Kubuntu) on my main non-work system. I saw people complaining about this, and counted myself lucky to not have this problem for the first few weeks. I went for about 20 days with the Steam client running in the background, but the system shutting off the display after a timeout as it should. So, clearly it is "possible" for the Steam client to behave itself.

However, now I have this problem. The one thing that I changed in Steam recently is turning on the option for "allow background processing of Vulkan shaders", once I realized that having that on would keep me from having to wait several minutes for a game to start while it processes shaders. Seemingly, once I turned that option on, I started having this issue with Steam blocking the monitor from turning off.

I tried turning that option back off and restarting the client, but it is still preventing the system from shutting the monitor off on a timeout. So, I guess I can't say for sure that it is connected, though I can't think of anything else that I changed in Steam at the same time. I guess I will be implementing the solution above with the little wrapper program and LD_PRELOAD.

[tatokis]

@AaronKelley did you happen to plug in any new HID devices during that period, or install any software to manage them?

[AaronKelley]

@AaronKelley did you happen to plug in any new HID devices during that period, or install any software to manage them?

No, the only HID devices I have connected are normal laptop stuff (keyboard/touchpad), a pretty plain USB mouse, and a DualSense controller that I connect via Bluetooth. But those have been in use the entire time that I've been on Kubuntu and I don't have any software to manage them installed beyond what normally comes with KDE.

[G2G2G2G]

I wouldn't be surprised if KDE disables keep awake for everything except what it deems correct. (so basically everything except video players and full screen video)
People with window managers like @sitedyno & I won't have that luxury though

maybe somehow updating the steam options triggered it's "keep awake" though? some internal setting that wasn't set until the "save" button in options got clicked?
maybe there's a .ini file somewhere in steam's 50000000 files with it set lmao

seems like windows actually had this issue years ago too
https://www.reddit.com/r/Steam/comments/a4f7wn/psa_if_your_pc_isnt_going_to_sleep_it_might_be/

@AaronKelley
#5532 (comment)
does his command work for you? I don't have that power management installed but KDE maybe does

[tatokis]

@AaronKelley Understood. Thanks. I was hoping we could maybe get a lead on something.

That said, I tested this again, and I can no longer reproduce it myself. I am not sure what changed.

Running

dbus-monitor destination=org.freedesktop.ScreenSaver

and

while true; do xprintidle; sleep 5; done

I see that Steam is inhibiting when I move my mouse, but not when I type. (Not sure why every now and then it uninhibits and re-inhibits immediately. Also not sure why it needs to do that when the cursor moves.)

But if I stop moving my mouse, after a few seconds, Steam just calls Uninhibit() over DBus, and stays like that, and xprintidle keeps counting up and doesn't reset. Eventually, my monitors turn off. Once I move the mouse again, everything wakes up, the X idle counter resets, and Steam starts calling inhibit again. We'll see what happens when I let it run overnight.

If I recall correctly, when I first encountered this issue, it happened to me even with all the Steam windows closed. But now even with the store (although it doesn't have a fancy background video playing at the moment) and friends open, it still doesn't happen.

[AaronKelley]

I wouldn't be surprised if KDE disables keep awake for everything except what it deems correct. (so basically everything except video players and full screen video)

I have noticed some power management oddities in KDE, with it sometimes failing to do things like lock the session based on the timeout that you have set in settings. (I ended up writing a script to "fix" this and lock the session after the screen turns off if KDE fails to do so itself. It looks like the bug is in the "kscreen" daemon which handles multiple monitors.) So, maybe it was "correcting" this behavior on its own, and somehow it is no longer doing so.

KDE actually shows active inhibitors at the top of the popup that appears if you click the tray battery icon; that's how I realized that Steam is responsible for this behavior.

@AaronKelley #5532 (comment) does his command work for you? I don't have that power management installed but KDE maybe does

That command does not work for me, but I can do "sudo systemd-inhibit --list" to get a list of blocking applications. Steam seems to pop in and out of the list.

If I recall correctly, when I first encountered this issue, it happened to me even with all the Steam windows closed.

I have also observed this with no Steam windows open.

[imikkl]

I've had this problem for years, and just recently discovered it was gone. Steam Beta Client just received a major rehaul, maybe this is what solved it - intentionally or unintentionally.

Not fixed for me (XFCE-4.19)

[G2G2G2G]

sudo systemd-inhibit --list

That list is showing computer sleep not monitor sleep. systemd won't list anything screen related (like full screen videos, steam, etc) as far as "monitor sleep" goes
for me, it won't show any video / steam etc.
It does shot things that would need to be cleaned up / put to sleep before the system was to sleep (suspend)

[gogoprog]

Is there anything new about this since Steam released a new UI?

[jouven]

Is there anything new about this since Steam released a new UI?

No, it still happens and previous workaround still works.

[Zorrototo]

To be fair I had the opposite situation where the system would go to sleep when I manually started big game updates before leaving, when I came back it was sleeping and the updates only downloaded a few GB.

I'll try to do more tests but it seems to be inconsistent with the expected behavior for sure.

[G2G2G2G]

@Zorrototo this is about monitor sleep not system sleep

[Dinth]

I think that system sleep is prevented by preventing monitor sleep?

[Zorrototo]

Yes it is about monitor sleep, but if the system goes to sleep it means the event prohibition is not working at all sometimes (and some other times, nothing is going on in Steam, and I can see that Steam Client Interface blocks monitor locking or sleep in KDE energy widget. As said these mechanism are not consistent with what is expected (when nothing is going on in Steam, do not prevent/prohibit anything, and if a game or a download is active, prevent monitor idling or system sleep).

[G2G2G2G]

Nope, you can go into system sleep which disables the "keep monitor awake" event that steam is doing.. which is via making xorg etc think a video is playing.
You can't go into monitor sleep, because it wakes up immediately

[flaviut]

🚀

Github has collapsed quite a few good comments above, including these two comments with a great workaround:

• Monitor no longer shuts off when idle #5607 (comment)
• Monitor no longer shuts off when idle #5607 (comment)

🚀