GNOME Bugzilla – Bug 687277
[REGRESSION] gnome-settings-daemon blanks the screen when lid is closed
Last modified: 2016-04-21 02:40:45 UTC
I upgraded to GNOME 3.6 on ArchLinux x86_64 last night. Now when I close the laptop lid, it unconditionally suspends in gnome-shell and fallback mode. In gnome-tweak-tool, both "Laptop lid close action on battery" and "Laptop lid close action when on AC" are both set to "Blank". Related: bug 638865 (https://bugzilla.gnome.org/show_bug.cgi?id=638865)
Adding this line to `/etc/systemd/logind.conf` will prevent the behavior: HandleLidSwitch=ignore However now when I go into gnome-tweak-tool and change lid behavior on battery and AC from "blank" to "suspend", it doesn't do actually suspend when I close the lid.
More data: ╭─ting@noa ~ ‹python-2.7.3› ‹ruby-1.9.3› ╰─➤ systemd-inhibit --list 127 ↵ 2012.10.31 20:50:40 CDT WHAT WHO WHY MODE UID PID handle-power-key:handle-suspend-key:handle-hibernate-key ting GNOME handlin...sses block 1000 776 sleep root inhibited delay 0 309 handle-lid-switch ting Multiple disp...ched block 1000 776 3 inhibitors listed. ╭─ting@noa ~ ‹python-2.7.3› ‹ruby-1.9.3› ╰─➤ gsettings get org.gnome.settings-daemon.plugins.power lid-close-ac-action 2012.10.31 20:50:49 CDT 'suspend' ╭─ting@noa ~ ‹python-2.7.3› ‹ruby-1.9.3› ╰─➤ gsettings get org.gnome.settings-daemon.plugins.power lid-close-battery-action 2012.10.31 20:53:33 CDT 'suspend'
The lid-close-{ac,battery}-action keys have been removed. We really want lid close to be the way to suspend. If you can't tolerate that, you can use systemd-inhibit to put an inhibitor in place that will keep it from happening.
Hi Matthias, I have modified systemd to get the behavior I want. As per bug 638865, there are many reasons why *always* suspending when closing lid is poor design. I don't see why GNOME should follow suit and copy OS X behavior. Even in OS X's case, they disable sleep when an external input device / monitor is plugged in. If you choose to disregard users' complaints, now the problem is why do we have these two ineffective settings in gnome-tweak-tool? Either they need to be removed or fixed. Displaying broken switches leads to poor user experience.
I just ran into this too. One of the first things I do when I install a laptop is use gnome-tweak-tool to disable suspending on lid close. I second the last comment. If you aren't going to fix it, then better remove those options from gnome-tweak-tool...
(In reply to comment #4) > Hi Matthias, > > I have modified systemd to get the behavior I want. As per bug 638865, there > are many reasons why *always* suspending when closing lid is poor design. I > don't see why GNOME should follow suit and copy OS X behavior. Even in OS X's > case, they disable sleep when an external input device / monitor is plugged in. We do that too, by default. You can override this with the org.gnome.settings-daemon.plugins.power lid-close-suspend-with-external-monitor setting. > If you choose to disregard users' complaints, now the problem is why do we have > these two ineffective settings in gnome-tweak-tool? Either they need to be > removed or fixed. Displaying broken switches leads to poor user experience. The settings are gone now.
(In reply to comment #6) > (In reply to comment #4) > > If you choose to disregard users' complaints, now the problem is why do we have > > these two ineffective settings in gnome-tweak-tool? Either they need to be > > removed or fixed. Displaying broken switches leads to poor user experience. > > The settings are gone now. To clarify - presumably the settings are gone in gnome-settings-daemon trunk? They're still there in 3.6.1, and gnome-tweak-tool actually hasn't been updated. I'll patch it tomorrow and send it upstream.
Is there a discussion somewhere of what trouble those options were causing? Would it possible to just have one checkbox to disable suspend on lid close, like the one for having an external monitor? That's all I care about.
They're removed in master, with this commit: http://git.gnome.org/browse/gnome-settings-daemon/commit/?id=58cb4eee64bbd8ca43111b1f80fdaacde8ad5f12 Can't remove them in 3.6, since the move to let systemd handle lid close has only happened in master. We should perhaps put that patch into the f18 package though, since that has the systemd patch and ignores the settings.
Ah, so this only affects Fedora 18, and somehow Arch Linux, but distributions that use stock GNOME 3.6.x would not be affected? In that case, the g-t-t fix should probably only go into master as well (I don't think there's a 3.6 branch right now, but it should be created in this case) and only cherry-picked for distros that carry the systemd patch.
Reported, with a patch, against gnome-tweak-tool: https://bugzilla.gnome.org/show_bug.cgi?id=687413
I really can't understand why remove this option if it is already implemented and it disturb nobody but it is pretty useful for a lot of people like me.
(In reply to comment #6) > (In reply to comment #4) > > Hi Matthias, > > > > I have modified systemd to get the behavior I want. As per bug 638865, there > > are many reasons why *always* suspending when closing lid is poor design. I > > don't see why GNOME should follow suit and copy OS X behavior. Even in OS X's > > case, they disable sleep when an external input device / monitor is plugged in. > > We do that too, by default. > You can override this with the > > org.gnome.settings-daemon.plugins.power lid-close-suspend-with-external-monitor > > setting. > > > If you choose to disregard users' complaints, now the problem is why do we have > > these two ineffective settings in gnome-tweak-tool? Either they need to be > > removed or fixed. Displaying broken switches leads to poor user experience. > > The settings are gone now. Closing the laptop lid when an external vga monitor is connected doesn't suspend the system but the monitor shutdown himself.
In case I hadn't mentioned this here yet: the command to override the default lid switch handling on a systemd system is: systemd-inhibit --what=handle-lid-switch \ --who=me \ --why=because \ --mode=block /bin/sh
(In reply to comment #13) > Closing the laptop lid when an external vga monitor is connected doesn't > suspend the system but the monitor shutdown himself. This happens to me too on unreleased F18. The intended behaviour is to not suspend on lid close if we are attached to an external monitor (+ input devices) right?
@Mattias Bengtsson: Intended behavior is to suspend in all circumstances, regardless of input devices or external monitors.
The behaviour depends on the org.gnome.settings-daemon.plugins.power lid-close-suspend-with-external-monitor setting. gnome-tweak-tool has UI for this.
$ dconf read /org/gnome/settings-daemon/plugins/power/lid-close-suspend-with-external-monitor false This is what's in dconf for me. Which I believe(?) also is the default. However, the attached screen still shuts down on laptop lid close. It probably doesn't suspend though, like Juan said above, so should this go in a separate bug instead?.
Suffering from the same issue. Suspend doesn't care about a monitor connected even if /org/gnome/settings-daemon/plugins/power/lid-close-suspend-with-external-monitor == false and just suspends. Had to set HandleLidSwitch=ignore in /etc/systemd/logind.conf Now the laptop only suspends if I tell it to by pressing the menu button... wich I GUESS is not the desired way it should work... right?! Am on Archlinux, Gnome 3.6.4, latest Kernel (3.6.9)
While suspending by default when the lid is closed is perfectly fine, removing this option (option!) from Gnome Tweak Tool -- which is obviously an external and advanced utility -- is definitely a bad idea. "Normal users" won't be installing it anyway and advanced users will be trying to use it anyway to change this behaviour. Not letting them do so will cause irritation without contributing any good. Additionally, this makes creating extensions that give you more control over what the lid triggers (e. g. https://extensions.gnome.org/extension/417/blank-on-lid/ ) very difficult and platform-dependent (because now it's systemd, acpid or the like that handle suspending). Moreover, by not taking any action and not inhibiting daemons (instead of forcing a suspend), Gnome Shell doesn't even ensure that the PC will suspend in the first place! (If there is no systemd/acpid/..., the PC just won't react, the screen won't even get locked!). Any comments on these points?
If you read the other bug, the option was removed from the tweak tool because support for that option was removed from Gnome. And the screen will get locked as normal after the idle timeout is reached. (And don't shoot the messenger. :-) I disagree with both of these decisions, I'm just explaining the current situation.)
gnome-power-manager is not involved in this anymore
Okay, thank you. Do you know whom I should contact (or which bug to consult) to try to convince them in order to have this functionality restored to Gnome?
This is the right place and they've been pretty clear that they won't reconsider it. See Bug 638865 for more details and discussion.
(In reply to comment #13) > Closing the laptop lid when an external vga monitor is connected doesn't > suspend the system but the monitor shutdown himself. You'll have to wiggle your mouse I'm afraid, it should bring the display back to life. It's fixed properly in master, and we have a test that specifically checks to avoid this particular problem.
The test case. commit 50badc695e22722d0f481c744f590fd8d8e39daa Author: Bastien Nocera <hadess@hadess.net> Date: Wed Jan 23 22:19:50 2013 +0100 power: Additional check in test_no_suspend_lid_close Check that we do not blank the screen when closing the lid, and a 2nd monitor is plugged in. https://bugzilla.gnome.org/show_bug.cgi?id=687277
I registered just to comment on this bug/feature. I use Gnome 3, love it, and frequently close my laptop's lid while jobs are running, like running custom backups scripts at night. I understand making suspend on lid close the default, but totally removing the ability to adjust this behaviour strikes me as a harmful change with no obvious benefit. I would really, really like to have the ability to blank the screen on lid close returned.
(In reply to comment #27) > I would really, really like to have the ability to blank the screen on lid > close returned. That won't be an option. You can block the lid-switch instead using systemd-inhibit. Read the bug comments.
I did and I did. However, if the switch isn't used at all, the screen doesn't blank when closed, as I understand it. So the backlight is left on and it runs down the batteries. Hardly a good "fix". Why is it so critical to remove this option from users? What hard could it have been causing?
I also utterly disagree with this decision. It seems a bit like copying all the bad habits or "negative features" from competing products...
Orest Tarasiuk: Exactly. Gnome3 is nice and effective if you can configure it but it's more and more difficult to. I'm spending my 2nd day searching for extensions and scripts to configure Gnome3 in such a way that had been half an hour before... I will never understand why it is good to disable options not used by everyone. It's cool to hook suspend on the lid but what if it is some users want it an other way? There were a couple of GOOD reasons listed above. The point is I want to change it back and forth time by time and not mess with scripts. Moreover: I am working with an external monitor with the lid closed. (Which I usually do.) I switch to console by Alt+Ctrl+F2 for some reason. Guess what? The computer goes to sleep.
(In reply to comment #31) > Moreover: > I am working with an external monitor with the lid closed. (Which I usually > do.) > I switch to console by Alt+Ctrl+F2 for some reason. > Guess what? > The computer goes to sleep. There's no guessing here. When you're at the console, systemd handles the lid, not gnome-settings-daemon running in some user's session in an inactive VT, and it sleeps by default when the lid is closed. Configure logind to not handle the lid switch, and it won't suspend.
Excuse me for my bad English, I didn't catch one point from the discussion. Which component is responsible for launching the suspend command on lid closing (when a user works in the Gnome shell)? Is it systemd or Gnome shell (i.e. gnome-settings-daemon or something like)?
OK, and do you think it's good design? I'm trying hard but still do not get why to take away that switch from the user that made them possible to decide when they want their computer send to sleep with the lid... > There's no guessing here. When you're at the console, systemd handles the lid, > not gnome-settings-daemon running in some user's session in an inactive VT, and > it sleeps by default when the lid is closed. Configure logind to not handle the > lid switch, and it won't suspend.
(In reply to comment #33) > Excuse me for my bad English, I didn't catch one point from the discussion. > Which component is responsible for launching the suspend command on lid closing > (when a user works in the Gnome shell)? > Is it systemd or Gnome shell (i.e. gnome-settings-daemon or something like)? systemd will actually suspend the machine when you close the lid. Various system components can prevent that by using block and delay inhibitors. Office runner and gnome-settings-daemon are examples of each one of those. (In reply to comment #34) > OK, and do you think it's good design? > I'm trying hard but still do not get why to take away that switch from the user > that made them possible to decide when they want their computer send to sleep > with the lid... Design doesn't come into it, the options weren't even user visible. From a code architecture stand-point, we have less moving parts, less bugs, and less corner cases. and something clean enough that we can have a test suite built on top of it. And despite the repeated assertions to the contrary, we didn't take away anything. the logind configuration and systemd-inhibit were mentioned a number of times in this bug already. And that discussion *still* doesn't have anything to do with the original bug report.
(In reply to comment #35) > And despite the repeated assertions to the contrary, we didn't take away anything. What do you mean? In GS 3.4, gnome-settings-daemon respected the gconf key inhibiting sleep mode on closing the lid. In 3.6, it doesn't.
(In reply to comment #36) > (In reply to comment #35) > > And despite the repeated assertions to the contrary, we didn't take away anything. > > What do you mean? In GS 3.4, gnome-settings-daemon respected the gconf key > inhibiting sleep mode on closing the lid. In 3.6, it doesn't. It still does in 3.6 as well as in 3.4. Maybe not in the downstream distribution you use, but that code upstream is the same as in 3.4. And there lies the rub. That code didn't work with systemd, and the interaction was completely broken for a number of cases. systemd works in a certain way, we adapted our code to work with systemd. In any case, there's no point carrying on this discussion, I've already explained how to get your laptop not to suspend when closing the lid.
(In reply to comment #37) > (In reply to comment #36) > > (In reply to comment #35) > > > And despite the repeated assertions to the contrary, we didn't take away anything. > > > > What do you mean? In GS 3.4, gnome-settings-daemon respected the gconf key > > inhibiting sleep mode on closing the lid. In 3.6, it doesn't. > > It still does in 3.6 as well as in 3.4. Maybe not in the downstream > distribution you use, but that code upstream is the same as in 3.4. And there > lies the rub. That code didn't work with systemd, and the interaction was > completely broken for a number of cases. systemd works in a certain way, we > adapted our code to work with systemd. > > In any case, there's no point carrying on this discussion, I've already > explained how to get your laptop not to suspend when closing the lid. Okay, this was unknown to me. I'm using Arch and the respective gconf key isn't considered (this also seems to be the case for other distributions). If the mentioned code is still in GS 3.6 upstream, what is the preferred method of inhibiting sleep as viewed from the upstream perspective?
Thank you. As a programmer I've understood the clear design, but I believe the point is that users (me too as a user) want to customize environment to meet their normal everyday activity. And they want to do this from the shell. I mean the Gnome shell, not CLI. And this is the root of the trouble.
(In reply to comment #40) > Just install dconf-editor and call it a day. Go to: org > gnome > > settings-daemon > plugins > power then set "lid-close-ac-action" and > "lid-close-battery-action" to whatever you need. The default is suspend but if > you set it to blank or nothing your computer will be able to continue playing > music, downloading files, running backgrounds tasks, etc. with the lid display > off but the rest of the unit running just fine. Unfortunately, I'm pretty sure this hasn't worked since GNOME 3.6. Those keys are now ignored, so it's impossible to configure GNOME with them (e.g. to behave differently on lid close on AC vs battery power).
(In reply to comment #41) > (In reply to comment #40) > > Just install dconf-editor and call it a day. Go to: org > gnome > > > settings-daemon > plugins > power then set "lid-close-ac-action" and > > "lid-close-battery-action" to whatever you need. The default is suspend but if > > you set it to blank or nothing your computer will be able to continue playing > > music, downloading files, running backgrounds tasks, etc. with the lid display > > off but the rest of the unit running just fine. > > Unfortunately, I'm pretty sure this hasn't worked since GNOME 3.6. Those keys > are now ignored, so it's impossible to configure GNOME with them (e.g. to > behave differently on lid close on AC vs battery power). I can confirm the methods I listed work. Running Gnome 3.6.3 in Fedora 18.
Hmm. I'm also running 3.6.3 on Fedora 18, and I can't seem to get my preferred setup (lid-close-ac-action = blank, lid-close-battery-action = suspend) to work whether or not systemd is set to handle lid close events. If systemd handles the lid switch, my system always suspends on lid close, and if not, it always does nothing. Comment #3 would seem to indicate this is the intended behaviour, although I guess I should probably do more testing to make sure there's nothing in my setup getting in the way.
(In reply to comment #43) > Hmm. I'm also running 3.6.3 on Fedora 18, and I can't seem to get my preferred > setup (lid-close-ac-action = blank, lid-close-battery-action = suspend) to work > whether or not systemd is set to handle lid close events. If systemd handles > the lid switch, my system always suspends on lid close, and if not, it always > does nothing. Comment #3 would seem to indicate this is the intended behaviour, > although I guess I should probably do more testing to make sure there's nothing > in my setup getting in the way. From a clean install of Fedora 18, (not sure what systemd handles it by default or not, would assume it does) and updating only the kernel (using version 3.8.5) I just simply have to install dconf-editor (version 0.14.1-3.fc18), make the aforementioned changes and I'm good. Both graphical and command line methods I mentioned work just fine. To confirm the test, I opened a music video on YouTube, began playing it before it could fully buffer even, closed the lid and enjoyed the song in its entirety proving it didn't sleep because A.) It could play the song and B.) My wi-fi adapter was able to finish loading the entire stream. Not sure how much hardware plays a part in this but I'm using an ASUS R503U with an AMD E8 1800 1.7GHz x2 64-bit APU with an ATI Radeon HD 7340 chipset. I'm in legacy bios mode as I disabled the prison that is UEFI.
(In reply to comment #43) > Hmm. I'm also running 3.6.3 on Fedora 18, and I can't seem to get my preferred > setup (lid-close-ac-action = blank, lid-close-battery-action = suspend) to work > whether or not systemd is set to handle lid close events. If systemd handles > the lid switch, my system always suspends on lid close, and if not, it always > does nothing. Comment #3 would seem to indicate this is the intended behaviour, > although I guess I should probably do more testing to make sure there's nothing > in my setup getting in the way. Just learned that the settings do not persist upon reboot however it remedies itself if dconf-editor is opened again. The configurations are still the way I left them so they don't reset upon reboot but apparently aren't read back into the system until I launch it. Strange... programming is not my skill set; repairs, design and bug testing are however, but with the problem isolated, hopefully someone can fix it easily.
(In reply to comment #47) > (In reply to comment #43) > > Hmm. I'm also running 3.6.3 on Fedora 18, and I can't seem to get my preferred > > setup (lid-close-ac-action = blank, lid-close-battery-action = suspend) to work > > whether or not systemd is set to handle lid close events. If systemd handles > > the lid switch, my system always suspends on lid close, and if not, it always > > does nothing. Comment #3 would seem to indicate this is the intended behaviour, > > although I guess I should probably do more testing to make sure there's nothing > > in my setup getting in the way. > > Just learned that the settings do not persist upon reboot however it remedies > itself if dconf-editor is opened again. The configurations are still the way I > left them so they don't reset upon reboot but apparently aren't read back into > the system until I launch it. Strange... programming is not my skill set; > repairs, design and bug testing are however, but with the problem isolated, > hopefully someone can fix it easily. EDIT: I actually don't need to open the setting again each time. Settings remain set and condition remedies itself after the first suspend. I.E. Apply settings, settings work for current session. Reboot, problem returns: system suspends on lid close, subsequent lid closes that session obey dconf settings. This is getting weirder by the minute. Not sure what the issue is anymore or if this is gnome's or systemd's fault anymore but at least I've narrowed this down a bit.
Just a friendly reminder to watch your language. I've hidden a few comments and also banned a person.
Ah, after re-reading the earlier comments I see that the config keys in question were only dropped after 3.6, but Fedora seems to carry cherry picked patches which probably account for the partially working behaviour. Sorry for the noise.
(In reply to comment #49) > Just a friendly reminder to watch your language. I've hidden a few comments and > also banned a person. I'm sorry Olav. I'm going to keep myself in line from now on. (In reply to comment #50) > Ah, after re-reading the earlier comments I see that the config keys in > question were only dropped after 3.6, but Fedora seems to carry cherry picked > patches which probably account for the partially working behaviour. Sorry for > the noise. So that explains the weird behavior. Anyways, I wanted everyone to know that I found a clean and pleasant work-around to this that's not nearly as messy as playing around with inhibitor locks. Hopefully someone can make a GUI solution in Gnome Tweak Tools or something that can do what I'm about to write here. All one has to do is uncomment the HandleLidSwitch= line in /etc/systemd/logind.conf and set the value to lock (This is case-sensitive. Users can also use "ignore" without quotes if they don't want it to immediately go to the lock screen) For good measure, you can also uncomment the LidSwitchIgnoreInhibited= line and change the value from yes to off. (Or add the lines if they do not exist) Source: www.freedesktop.org/software/systemd/man/logind.conf.html I tested this method and it worked on systemd based distros such as Fedora and Arch. It think it's safe to assume that it will work on all systemd distros. I'm going to open a feature request to see if someone can implement this clean solution. All that's left to figure out how to achieve this on distros without systemd.
(In reply to comment #51) > All one has to do is uncomment the HandleLidSwitch= line in > /etc/systemd/logind.conf and set the value to lock (This is case-sensitive. > Users can also use "ignore" without quotes if they don't want it to immediately > go to the lock screen) For good measure, you can also uncomment the > LidSwitchIgnoreInhibited= line and change the value from yes to off. (Or add > the lines if they do not exist) Thank you for this. I was using the logind configuration to work around this issue, but I was unaware I could make use of options beyond "ignore". I'm not sure this is something GNOME Tweak Tool could handle though, considering it's a system configuration file that needs root permissions to edit. That's not to say there couldn't be a GUI tool for modifying systemd configuration, but it would probably be outside the GNOME scope. I'm curious as to how this is handled on non-systemd distros. Do upstart/initd/etc. have their own event handling, or does it all go straight to the DE?
Ok, I did understand how to disable suspending when the lid closes (editing /etc/systemd/logind.conf) Now is there a way to *disable* the suspend for AC power and *enable* the suspend for battery? Quite frankly, I have little desire to edit system configuration files every time I plugin in or out my power cord. Also, will there be graphical settings for this? (In reply to comment #3) > The lid-close-{ac,battery}-action keys have been removed. > We really want lid close to be the way to suspend. I mean, that's just like your opinion man... But I really don't get the desire of the GNOME project to force behaviour on people instead of presenting a choice. If I wanted an operating system that decides over my head what I want and need, I would use Mac OS.