GNOME Bugzilla – Bug 681869
Default to suspend after 20 minutes of inactivity
Last modified: 2018-03-15 16:15:35 UTC
The new user menu design assumes that the primary way to suspend a desktop machine is simply to let it timeout and suspend on its own. This is great behaviour, since it means that you don't have to worry about managing your machine and can leave it to take care of itself. There are questions about our ability to suspend and resume successfully of course - it would be good to hear thoughts on that.
It's worth noting there was a default 30 minute suspend introduced *accidentally* during an earlier cycle, and that wasn't liked by many: https://bugzilla.redhat.com/show_bug.cgi?id=742685 https://bugzilla.gnome.org/show_bug.cgi?id=660395 There were also some mailing list threads, but I don't have those links handy right now.
I often do network transfers (uploading silly YouTube videos) overnight. This would kill that.
(In reply to comment #2) > I often do network transfers (uploading silly YouTube videos) overnight. This > would kill that. Is it possible to inhibit suspend in that case (it should still suspend if it's a laptop and you close the lid, I might add)?
I doubt it's possible to inhibit suspend in that case.
I don't think you're ever going to catch all the 'I like leaving the machine doing X' cases to inhibit suspend for all of them, anyway. Whitelists / blacklists are a horrible way to spend your time. Of course, you can always just say 'people who like to leave their machines doing things can change the timeouts', but do you want to do that?
(In reply to comment #2) > I often do network transfers overnight. This would kill that. +1. I'm pretty annoyed that F17 by default goes to hibernate/sleep/whatever while I try to run "jhbuild update meta-gnome-core" over night.
(In reply to comment #0) > There are questions about our ability to suspend and resume successfully of > course - it would be good to hear thoughts on that. Suspend is not something the kernel developers care much about. Regressions in sleep (i..e suspend worked yesterday, but not with this new kernel version) are not blockers to kernel developers. Suspend usually works. It's the resume that's the tricky bit. It's probably worth saving unsaved files and that kind of thing before we do an automatic suspend as when we accidentally turned this on before we caused outrage as one failed resume would loose data. The situation kinda sucks, but it's the way it is. :(
If anything this should be opt in rather then opt out. There are a lot of reasons why people keep desktops running for a long time period. And not every app does inhibit suspend in such cases (and for some it does not make sense). Sometimes I just leave it on to not miss chat messages, having chat applications inhibit suspend does not make much sense.
(In reply to comment #8) > If anything this should be opt in rather then opt out. > > There are a lot of reasons why people keep desktops running for a long time > period. And not every app does inhibit suspend in such cases (and for some it > does not make sense). > > Sometimes I just leave it on to not miss chat messages, having chat > applications inhibit suspend does not make much sense. I don't see how it being opt-in helps with any of those cases.
(In reply to comment #9) > (In reply to comment #8) > > If anything this should be opt in rather then opt out. > > > > There are a lot of reasons why people keep desktops running for a long time > > period. And not every app does inhibit suspend in such cases (and for some it > > does not make sense). > > > > Sometimes I just leave it on to not miss chat messages, having chat > > applications inhibit suspend does not make much sense. > > I don't see how it being opt-in helps with any of those cases. By not catching the user by surprise. "wtf why did my system suspend" vs. "I want to save power" (which will cause the user to go to the power panel and notice the autosupsend feature).
Created attachment 235897 [details] [review] power: Default to suspend after 30 minutes of inactivity
(In reply to comment #11) > Created an attachment (id=235897) [details] [review] > power: Default to suspend after 30 minutes of inactivity As I have already said I don't think that this is a good idea ...
(In reply to comment #12) > As I have already said I don't think that this is a good idea ... I'm not asking for opinions here though. You've already made it clear that you don't like this, you don't need to comment every time I move my patches to bugzilla.
(In reply to comment #13) > every time I move my patches to bugzilla. I said I don't like the idea once it got proposed ... now you attach a patch that implements it I told you that my concerns still got not addressed. You seem to not give a fuck about it so go ahead there is no point in having a discussion like this.
Another case that I found was that a user was playing a video game, and the screen blanked on them, because he was using a controller, and that's not tracked for IDLETIME. Escalating this to suspend is the wrong thing to do. Maybe we can have IDLETIME tracked with gamepads and controllers, though. Oh, and the game didn't use inhibit because apparently lots of users leave the game up and expect their screen to blank if they're not playing it.
(In reply to Jasper St. Pierre from comment #15) > Another case that I found was that a user was playing a video game, and the > screen blanked on them, because he was using a controller, and that's not > tracked for IDLETIME. Escalating this to suspend is the wrong thing to do. > Maybe we can have IDLETIME tracked with gamepads and controllers, though. I've sent patches to SDL to implement that, so that's fixed AFAICT. > Oh, and the game didn't use inhibit because apparently lots of users leave > the game up and expect their screen to blank if they're not playing it. Is that really the case? If so, please report the bug against SDL, because that's not how it's behaving right now.
(In reply to Jasper St. Pierre from comment #15) > Oh, and the game didn't use inhibit because apparently lots of users leave > the game up and expect their screen to blank if they're not playing it. You can't have your cake and eat it... the game should obviously inhibit when it is being played, and drop the inhibitor when it is idle/paused.
Still heavily against the core idea of suspending after 30 minutes of idle time. Two years later, I'm now more network-connected than ever. I'm still doing long-running network transfers (still making dumb YouTube videos), but now I'm also expected to be on IRC full-time and going to lunch shouldn't be enough to kill notifications from IRC. I'm often also doing long-running tasks (mainly exporting / rendering such dumb YouTube videos), and losing a day of work because I forgot to press an inhibit button isn't great. And that's still nothing to do with video games or SDL. It seems they implemented a suspend inhibitor in the two years since I left that comment, though they originally gave me the rationale that video games should eventually blank when paused.
Created attachment 366876 [details] [review] power: Default to suspend after 20 minutes of inactivity According to the EU Commission Regulation No 801/2013, amending Regulation (EC) No 1275/2008: " The default period of time after which the power management function, or a similar function, switches the equipment automatically into a condition providing networked standby shall not exceed 20 minutes. " (Full text at: http://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32013R0801&from=EN )
FWIW at Endless we have to do similar things to meet Califonia Energy Commission standards to ship into the USA: http://www.energy.ca.gov/appliances/2012rulemaking/documents/2011-08-31_workshop/proposals/Proposal_Information_for_computers_TN-62465.pdf This specifies a 30 minute sleep mode.
(In reply to Bastien Nocera from comment #19) > Created attachment 366876 [details] [review] [review] > power: Default to suspend after 20 minutes of inactivity This seems good to me!
Created attachment 366878 [details] [review] power: Default to suspend after 20 minutes of inactivity According to the EU Commission Regulation No 801/2013, amending Regulation (EC) No 1275/2008: " The default period of time after which the power management function, or a similar function, switches the equipment automatically into a condition providing networked standby shall not exceed 20 minutes. " (Full text at: http://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32013R0801&from=EN ) Though this addition only seems to be applicable to "networked equipment", the original directive and its 2008 "ecodesign" regulation mentions that computers are covered (as "Information technology equipment intended primarily for use in the domestic environment"), and that: " When equipment is not providing the main function, or when other energy-using product(s) are not dependent on its functions, equipment shall, unless inappropriate for the intended use, offer a power management function, or a similar function, that switches equipment after the shortest possible period of time appropriate for the intended use of the equipment, automatically into [standby mode]. " (Full text at: http://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32008R1275&from=EN) Furthermore, the EnergyStar standard that allows shipping into the USA mentions that, for most computers types: " Sleep Mode shall be set to activate after no more than 30 minutes of user inactivity. " (Full text at: http://docketpublic.energy.ca.gov/PublicDocuments/16-AAER-02/TN213577_20160909T143121_ENERGY_STAR_Product_Specification_for_Computers_Eligibility_Cri.pdf)
Attachment 366878 [details] pushed as 2fdb48f - power: Default to suspend after 20 minutes of inactivity
Unfortunately, the power UI in gnome-control-center (https://git.gnome.org/browse/gnome-control-center/tree/panels/power/power.ui) has a discrete set of supported values, and 20 minutes is not one of them. In our testing on Endless, the UI shows "2 hours" when the default of 20 minutes is set. Can we drop this default timeout to 15 minutes to map to the available settings? I suppose we could alternatively modify gnome-control-center to add a 20 minute option, though we would have to propagate that change to all the translations. Thanks.
(In reply to Roddy Shuler from comment #24) > Unfortunately, the power UI in gnome-control-center > (https://git.gnome.org/browse/gnome-control-center/tree/panels/power/power. > ui) has a discrete set of supported values, and 20 minutes is not one of > them. In our testing on Endless, the UI shows "2 hours" when the default of > 20 minutes is set. Can we drop this default timeout to 15 minutes to map to > the available settings? > > I suppose we could alternatively modify gnome-control-center to add a 20 > minute option, though we would have to propagate that change to all the > translations. Please file a bug against gnome-control-center, we have a couple of weeks to make string changes still.
Filed as https://bugzilla.gnome.org/show_bug.cgi?id=792890
I suggest we immediately revert this, in a 3.28.0.1 release, until we have a solution for bug #705942 in place. See https://bugzilla.gnome.org/show_bug.cgi?id=705942#c21.
(In reply to Michael Catanzaro from comment #27) > I suggest we immediately revert this, in a 3.28.0.1 release, until we have a > solution for bug #705942 in place. No. The bug is in gnome-shell which handles idle monitoring, not in gnome-settings-daemon (whether its configuration, or in the power plugin).
Yeah, I understand that this change is itself fine, and that it just uncovered a problem elsewhere. Does that really matter? We're trying to build an integrated product....
It looks to me like the patch was applied to comply with EU and US regulations for power management. Reverting the patch and possibly breaking compliance doesn't seem like a good solution to me.