GNOME Bugzilla – Bug 731241
Suspend on idle not working, if screen is locked
Last modified: 2014-08-01 14:03:09 UTC
I am using 3.12.2 version of gnome on Arch linux. The suspend on idle function on my system is broken. The bug is similar to one reported in https://bugzilla.gnome.org/show_bug.cgi?id=712706, except the fix there is not working. Steps to reproduce: 1. Set the sleep-inactive-ac-timeout to 60. $ gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout 60 2. Lock screen and wait for 60 seconds. 3. After about 50 seconds the screen activates, but the computer does not suspend after 60 seconds. The bug persists even after disabling notifications in the lock-screen. I have attached gsd debug log.
(In reply to comment #0) > I have > attached gsd debug log. I don't see it.
Created attachment 277965 [details] gsd debug log
Sorry!
Created attachment 278031 [details] [review] power: Don't add an activity watch when going to sleep We don't want spurious events that come in at this point to prevent us from sleeping when we already decided that we should sleep.
Created attachment 278032 [details] [review] power: Run the user activity handler on resume The previous commit removed the user active watch when going to sleep but we still need to run the handler when resuming. Let's do it from logind's signal that tells us we are resuming.
(In reply to comment #3) > Sorry! It's ok. Thanks for the log. Can you try both of these patches? I can't reproduce the bug myself since I seem to have well behaved input devices.
Created attachment 278054 [details] gsd debug log after applying two patches. I see the same behaviour after applying the two patches. gsd debug log attached.
Created attachment 278150 [details] [review] power: Cancel the previous activity watch before creating a new one If we had an activity watch set up previously that didn't trigger we could end up running the handler more than once needlessly.
Created attachment 278151 [details] [review] power: Don't add an activity watch when going to sleep We don't want spurious events that come in at this point to prevent us from sleeping when we already decided that we should sleep.
Created attachment 278152 [details] [review] power: Run the user activity handler on resume The previous commit removed the user active watch when going to sleep but we still need to run the handler when resuming. Let's do it from logind's signal that tells us we are resuming.
Created attachment 278153 [details] [review] power: Add a small delay before sleeping where we ignore input events
The previous patches couldn't have worked. Please try these.
Created attachment 278155 [details] gsd debug log Sorry, there's still no change in the behaviour.
Created attachment 278227 [details] [review] power: Don't show the sleep notification when the screen is blank Showing the notification in this case means that we have to turn on DPMS which unfortunately has the side effect of causing the X server to update all devices' last event time which in turn prevents our sleep idle handler to never run. -- Ok, for some reason I completely missed that you need to lock the screen first. Indeed, in that case I was able to reproduce this. I tracked this down to the X server as explained above. Unfortunately it doesn't seem like is can easily be fixed there. There was a similar problem which was fixed in http://cgit.freedesktop.org/xorg/xserver/commit/?id=a32d717ac64b21e15a5736ae4981cdd32f2da56b but it caused a regression that was then fixed in http://cgit.freedesktop.org/xorg/xserver/commit/?id=001ce71dc11287dc94cc2fbc5d35677c046e6c04 i.e. I think this patch is the best we can do.
(In reply to comment #14) > Created an attachment (id=278227) [details] [review] > power: Don't show the sleep notification when the screen is blank > > Showing the notification in this case means that we have to turn on > DPMS which unfortunately has the side effect of causing the X server > to update all devices' last event time which in turn prevents our > sleep idle handler to never run. Having to work around this is atrocious. > Ok, for some reason I completely missed that you need to lock the > screen first. Indeed, in that case I was able to reproduce this. > > I tracked this down to the X server as explained above. Unfortunately > it doesn't seem like is can easily be fixed there. There was a similar > problem which was fixed in > > http://cgit.freedesktop.org/xorg/xserver/commit/?id=a32d717ac64b21e15a5736ae4981cdd32f2da56b > > but it caused a regression that was then fixed in > > http://cgit.freedesktop.org/xorg/xserver/commit/?id=001ce71dc11287dc94cc2fbc5d35677c046e6c04 > > i.e. I think this patch is the best we can do. I don't think we should be working around this. Or working around this in gnome-settings-daemon. In the worst of worst cases, we should work around this in gnome-shell though that would get complicated (you'd need to set up new backing alarms for all the running notifications with different values). The whole reason we show a notification is so that the user knows that the machine will go to sleep. For what it's worth, notifications can come from elsewhere, waking up the screen to show the notification, and resetting the timeout. That means that a machine which has regular mail notifications would never sleep. That's broken. I'd punt this to X.org.
(In reply to comment #15) > The whole reason we show a notification is so that the user knows that the > machine will go to sleep. For what it's worth, notifications can come from > elsewhere, waking up the screen to show the notification, and resetting the > timeout. That means that a machine which has regular mail notifications would > never sleep. That's broken. > > I'd punt this to X.org. Indeed, other notifications will cause the same problem. Peter do you think this can be fixed in the X server?
Pretty sure the commit causing this one is: http://cgit.freedesktop.org/xorg/xserver/commit/?id=41d4beb2616ceb3f1a1b8694733e85bae70de59a I'm chasing this up with Egbert to get more info
Finally figured out what should be a solution to this, patch is on the xorg-devel list: http://patchwork.freedesktop.org/patch/29412/
(In reply to comment #18) > Finally figured out what should be a solution to this, patch is on the > xorg-devel list: http://patchwork.freedesktop.org/patch/29412/ Thanks. I tested it and it does fix this bug. Closing this report.
Upstream commit: http://cgit.freedesktop.org/xorg/xserver/commit/?id=578b9283bcc129d0a35fabe2637c7622085ef1e8
*** Bug 728939 has been marked as a duplicate of this bug. ***