search

ValveSoftware / steam-for-linux

Issue tracking for the Steam for Linux beta client
4.13k stars 174 forks source link

Monitor no longer shuts off when idle #5607

Open saellaven opened 5 years ago

saellaven commented 5 years ago

Your system information

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

I've been having this issue since at least before issue https://github.com/ValveSoftware/steam-for-linux/issues/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:

gogoprog commented 5 years ago

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

2018-10-23_11 43 38

mphe commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

Any news on this?

ZacJoffe commented 5 years ago

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 commented 5 years ago

Can confirm also on ubuntu 18.10 xfce 4.12

patlefort commented 5 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

happens here too, and its quite annoying

mDuo13 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

tripkin commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

g0ga commented 4 years ago

Same thing here. Archlinux current. Monitor blanks but never turns back light off when steam is running.

nipkownix commented 4 years ago

Same here.

metatoaster commented 4 years ago

As a workaround to the dbus DPMS inhibition issue, simply start the Steam client from the console with DBUS_SESSION_BUS_ADDRESS environment variable set to an invalid location. Example on how this can be achieved can be done, and some warnings that steam writes out when it can't find dbus follows:

$ DBUS_SESSION_BUS_ADDRESS=unix:abstract=/dev/null steam
...
(steam:22879): libappindicator-WARNING **: 22:02:17.398: Unable to get the session bus: Could not connect: Connection refused
...
(steam:22879): LIBDBUSMENU-GLIB-WARNING **: 22:02:17.452: Unable to get session bus: Could not connect: Connection refused

Note that this workaround will break things such as the app indicator icon at the tray and possibly other features that depend on dbus, but until Valve fixes this issue, this may be an acceptable compromise to allow steam to stay running to download updates without keeping the screen on (or have it turn back on randomly despite already forcing the screen off using xset dpms force off; especially useful for users with multiple screens connected using Display Port with buggy video card/drivers that don't play nice with desktop settings/window locations when they are manually powered off).

Yes, again, this is a sledgehammer solution - a solution that blocks just that org.freedesktop.ScreenSaver Inhibit message would be much more preferable.

ortango commented 4 years ago

@metatoaster unfortunately that doesn't work on my machines.

i've posted on this report in the past - i'm running without either of the dbus services that steam is trying to use for this (and still get no blanking)... maybe steam is falling back to some other method of screensaver inhibition (one where my X idle timer continually increases) in this case.

side note: i'd imagine that other DE users will see the same as me since steam is only trying freedesktop & gnome connections. i don't know if there is some abstraction for these dbus service names, but the way xdg-screensaver works i'd guess not.

h1z1 commented 4 years ago

Since Steam uses it for offload and at least with NVIDIA any process using the GPU will block blanking... I'm not surprised.

nvidia-smi will show what processes are using it.

safield commented 4 years ago

I am seeing this behaviour on Linux Mint 19.2 with Cinnamon desktop.

glubsy commented 4 years ago

I've also started experiencing this issue since recently. I have to shut down steam in order to be able to use xset dpms force off (which gets waken up after a few seconds otherwise).

Specs.

camelCaseSucks commented 4 years ago

I only started having this issue after signing up for the beta client when the new library was released. When the new library left beta, I did too but the problem remained. Surprised to see that the bug has been around for so long, and disappointed that it hasn't been fixed after all this time.

intercaetera commented 4 years ago

Happens to me as well, Arch Linux with i3.

cl0ne commented 4 years ago

Arch Linux with KDE, same issue.

laichiaheng commented 4 years ago

Manjaro Linux with Gnome3, still have this issue.

Iiridayn commented 4 years ago

Yep, been having this issue for quite a while myself. Recently mismatched my lib32 nvidia drivers w/the 64-bit ones, and Steam wasn't starting for a bit, and my display power management was working, which was wonderful. Got Steam working again last night and the issue returned.

adnieman commented 4 years ago

Almost a year and a half, and no solution. Come on Valve! Put a checkbox in settings that allows us to disable it. I want to be able to leave the client running and have my screens turn off when I go to sleep. I'm gonna quote Skwisgar Skwigelf: "This is d**dos!"

Muffindrake commented 4 years ago

I kindly request comments on why the clearly-identified problem breaking monitor sleep cycles hasn't been dealt with after all this time. Is there any specific setup that Valve doesn't want to break? I honestly don't understand. Shutting down Steam when you leave your machine unattended is not an option if you use Steam's messaging features to keep in touch with people.

tripkin commented 4 years ago

Likely because it is not considered critical to the operation of steam. And also, likely, because it's dev's don't have this particular use case. Also, not so certain they even read these comments...

NotMrFlibble commented 4 years ago

Shutting down the Steam client is, arguably, an option if you're merely using its messaging features as you're likely to have the mobile app to fall back on.

However, while a download is in progress, shutting it down isn't an option but is a time when it is reasonable to leave it unattended. For that, if nothing else, this needs to be fixed.

Ilazki commented 4 years ago

Likely because it is not considered critical to the operation of steam

Maybe not, but not being able to leave Steam running does cost them sales. Probably not enough to use it as an argument for making it a high-priority fix, but "I'm not buying things because I'm not using it" goes against Steam's purpose as a storefront.

When I discovered that Steam was inhibiting display power management, the first thing I did was stop running Steam unless I needed to launch a game. As a workaround, I instead started to use the web chat at https://steamcommunity.com/chat/ in Chrome, made to run as a standalone window (via ⋮> More tools > Create shortcut), which looks and acts mostly the same, but doesn't affect power management.

That means I only use Steam to launch games or buy ones I already know I want, so I miss out on announcements and random sales, I don't impulse buy, I don't browse as often, and I stopped using the discovery queue feature as much. This has been a problem for years, meaning years of reduced buying as a result.

tripkin commented 4 years ago

I totally agree, and that is how I use steam now. I start it up when a game needs it, and then it gets shut down. No impulse buys, no announcements, and so forth. It really is a case of lost sales.

adnieman commented 4 years ago

I think they're trying to get us to accept that it happens, because a bug that stays in long enough becomes a feature... Just sayin'

erikhakansson commented 4 years ago 
$ dbus-send --print-reply --dest=org.gnome.SessionManager /org/gnome/SessionManager/Inhibitor2400 org.gnome.SessionManager.Inhibitor.GetAppId
method return time=1581545957.566430 sender=:1.14 -> destination=:1.637 serial=21651 reply_serial=2
   string "My SDL application"

For some reason Steam presents itself as My SDL application.

$ dbus-send --print-reply --dest=org.gnome.SessionManager /org/gnome/SessionManager/Inhibitor2400 org.gnome.SessionManager.Inhibitor.GetReason
method return time=1581545778.878954 sender=:1.14 -> destination=:1.591 serial=21554 reply_serial=2
   string "Playing a game"

It also reports "Playing a game" as reason for inhibiting sleep. And this is despite the fact that I'm not playing a game. There's no game running. Only the Steam client itself. For some reason Steam (or "My SDL app")

Each SessionManager Inhibitor only lives for a few seconds, and dbus-send --print-reply --dest=org.gnome.SessionManager /org/gnome/SessionManager org.gnome.SessionManager.GetInhibitors might return empty for a while, but if you try again in 10 seconds, there you have it.

diego-treitos commented 4 years ago

I can confirm this behaviour. I tested with xset dpms 10 10 10. If I start steam and wait 10 seconds, the monitor goes off. But if I start a game and then I close it, the monitor won't go off anymore.

Monitoring with dbus-monitor --session I can see that after starting a game (and closing it), steam keeps sending screensaver inhibit requests like this over and over again:

method call time=1581678387.408841 sender=:1.4570 -> destination=org.freedesktop.ScreenSaver serial=47 path=/org/freedesktop/ScreenSaver; interface=org.freedesktop.ScreenSaver; member=Inhibit
   string "My SDL application"
   string "Playing a game"

It will never sent the Uninhibit request, so the screen just won't go off. The only solution is to kill or stop steam.

patlefort commented 4 years ago

My work around at the moment is to use this script to start steam:

#!/bin/sh

xdg-dbus-proxy "$DBUS_SESSION_BUS_ADDRESS" "$XDG_RUNTIME_DIR/steam-bus-proxy" --filter --call=org.freedesktop.DBus.*=* --call=com.feralinteractive.GameMode.*=* &
DBUS_SESSION_BUS_ADDRESS="unix:path=$XDG_RUNTIME_DIR/steam-bus-proxy" steam
kill %1

The script use xdg-dbus-proxy to allow only methods in org.freedesktop.DBus to pass. Unfortunately, it doesn't allow allowing everything to pass but some things.

(Edit) I've added com.feralinteractive.GameMode in the white list.

NotMrFlibble commented 4 years ago

kill %1 would be much better than killall xdg-dbus-proxy: you don't want to kill other instances.

patlefort commented 4 years ago

kill %1 would be much better than killall xdg-dbus-proxy: you don't want to kill other instances.

You're right. I've edited my comment.

dhouck commented 4 years ago

Maybe they’ll consider adding a blocklist in addition to the current filtering options.