GNOME Bugzilla – Bug 627290
[PATCH] Don't wait for screensaver that isn't locking
Last modified: 2020-11-06 20:14:13 UTC
If gnome-screensaver isn't running or for whatever reason isn't fulfilling dbus requests, when gnome-power-manager asks it to Lock itself, g-p-m will wait 5s for the screensaver to finish locking before timing out and continuing. You can see this if you: 0) Make sure you have the gconf setting to lock screensaver on suspend 1) Close your laptop lid (note how long it takes for your computer to suspend) 2) Open lid, resume 3) killall gnome-screensaver 4) Close your laptop lid again (note again how long it takes) Both #1 and #4 should be the same length of time, but #4 actually takes 5s longer. Really, if the Lock dbus request didn't go through, g-p-m shouldn't waste its time waiting.
Created attachment 168217 [details] [review] Proposed patch
The reason that the request is async was that gnome-screensaver called into gnome-power-manager and there was a deadlock condition. I'm not sure if that's still the case. If we're doing a sync call to gss, I don't think we still need to do the "while (ret && ! gpm_screensaver_check_running (screensaver))" thing either.
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years. If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/gnome-power-manager/-/issues/ Thank you for reporting this issue and we are sorry it could not be fixed.