protonscr

Steam dbus ScreenSaver Inhibit lock not being released on exit.

steamclosed duplicateSteam client
ValveSoftware/steam-for-linux#11275 · opened 2024-09-18 by husjon · updated 2024-10-17 · 7 comments · github
Hhusjon 2024-09-18 github

Your system information

  • Steam client version (build number or date): 1726604483

  • Distribution (e.g. Ubuntu):
    NixOS

  • Opted into Steam client beta?: [Yes/No]
    No

  • Have you checked for system updates?: [Yes/No]
    Yes

  • Steam Logs: [generate by running this command in a terminal tar -zcvf ~/Desktop/steam-logs.tar.gz ~/.steam/steam/logs]
    steam-logs.tar.gz

  • GPU: Nvidia/Intel/AMD
    AMD

Please describe your issue in as much detail as possible:

Describe what you expected should happen and what did happen. Please link any large code pastes as a Github Gist

The issue
Steam client does not release the screensaver inhibit lock after exiting which makes it so idle daemons (using dbus) that should trigger different actions when a system is idle (i.e. control DPMS to turn off monitors etc) are not able to do so.
(this have also been testing with the beta client)

Expected result
The org.freedesktop.ScreenSaver=UnInhibit message should be sent during shutdown of the Steam client so that idle daemons can properly trigger actions when a system is idle.

What happens
During startup of Steam, the clients sends an Inhibit message to /org/freedesktop/ScreenSaver which makes it so that idle daemons are not triggered (i.e triggering DPMS to turn of monitors etc)
Example message:

method call time=1726674583.493806 sender=:1.6949 -> destination=org.freedesktop.ScreenSaver serial=22 path=/org/freedesktop/ScreenSaver; interface=org.freedesktop.ScreenSaver; member=Inhibit
   string "Steam"
   string "Client interface"

Under normal operations when leaving Steam in the background on an inactive workspace, one can observe that it does release the lock after a couple of seconds of being idle (about 30 seconds) allowing the idle daemons to work normally.

method call time=1726674613.607698 sender=:1.6949 -> destination=org.freedesktop.ScreenSaver serial=23 path=/org/freedesktop/ScreenSaver; interface=org.freedesktop.ScreenSaver; member=UnInhibit
   uint32 1345

However this does not happen when Steam is told to exit.
As one switches back to the workspace or just gives the Steam client window focus in general a new inhibit message is sent since it is now active, and while exiting the Uninhibit message is not sent.

I made a quick video showing the dbus messages being sent during a quick startup and exit sequence (about 40 seconds).
https://youtu.be/6bQpwzxmRZ4

In the video we can also see the steam tray icon (bottom left) lingers for a few seconds but still the message is not sent.

Steps for reproducing this issue:

  1. Start terminal with the command dbus-monitor path=/org/freedesktop/ScreenSaver
  2. Start Steam
  3. Observe a couple of Inhibit / UnInhibit message being sent, Inhibit being the last state sent
  4. Exit Steam and observe UnInhibit not being sent.
Hhusjon 2024-09-23 github

@TTimo #5607 unfortunately seem to not be related as it is regarding DPMS being blocked while Steam is running.
My issue is however about Steam leaves its Inhibit lock dangling even after Steam has been closed.
After reading through the linked issue, I found #11207 where you mentioned the following:

There was a recent fix for gldriverquery crashing during shutdown. Maybe that has an impact on this? If this lock is negotiated via dbus, shouldn't the setup be smart enough to lift the lock if the process dies?

Oortango 2024-10-17 github

My issue is however about Steam leaves its Inhibit lock dangling even after Steam has been closed.

the way i see it, that quote you have is correct.

it is the case that the dbus service should be watching for client disconnects (by following NameOwnerChanged messages, which should include crashes afaik) and removing its cookies, and possibly lock. that is the responsibility of the org.freedesktop.screensaver service.

which is also the behavior of Xss if the dbus service is not running. the suspend lock entry is kept by resource id based on client's mask. so when X client disappears, the lock entries will be cleared from Xss, and inhibit removed if there are no more locks.

but in your video, the inhibit lock that is not release is the steam client lock....

Hhusjon 2024-10-17 github

@ortango I am on wayland so no Xss for me, so in that case it would be hypridle that would be responsible if I read your comment correctly.

Just saw the issue you created about the persistent inhibit lock, I'll keep an eye on it as well.

Oortango 2024-10-17 github

so in that case it would be hypridle that would be responsible if I read your comment correctly.

Yeah. it doesn't handle the NameOwnerChanged signal which would explain what you saw. Might be worth reporting to hypridle.

Hhusjon 2024-10-17 github

Thanks, will do

TTTimo 2024-10-17 github

Also note that due to a snafu on our end, it looks like this fix:

There was a recent fix for gldriverquery crashing during shutdown.

Didn't actually make it into steam beta client until very recently.

Upstream links