Description of problem: When closing the lid of a laptop to suspend the machine. When you reopen the laptop, the system wakes briefly before suspending again. Waking the system again, after this allows you to continue work. How reproducible: Always Steps to Reproduce: 1. Install MATE on a laptop 2. Close laptop lid 3. Reopen laptop Actual results: Laptop resumes, then suspends immediately. Expected results: Should resume, and display unlock screen Additional info: I have already removed xscreensaver, and am using mate-screensaver. The machine has been rebooted, and xscreensaver autoruns removed. The machine is set to use suspend on lid close both on AC or battery.
f18+ systemd provides support for this. Looks like mate-power-manager needs to learn to inhibit that feature. Here's a snippet from lennarts mass-bug-filing to kde about it awhile back: With systemd-190 (in F18) we changed the handling of the sleep key/power key/lid switch. systemd/logind will now always act on this regardless if we have a text console or a graphical session in the foreground. I am not sure whether KDE previously currently handles these keys on its own. If so, and if it wants to continue to do so (maybe in order to present a dialog or so if the key is pressed?) it needs to take new inhibitor locks to tell systemd/logind to stop handling these keys while KDE is running and in the fg. Ideally, KDE would take these locks as part of its session manager in native C++. If that's not desired, then there's a temporary hack, by wrapping invocation of the KDE session manager in "systemd-inhibit", which is a command line iface for taking these inhibitor locks: systemd-inhibit --what=handle-power-key:handle-sleep-key:handle-lid-switch kde-session For more information about all of this: https://bugzilla.gnome.org/show_bug.cgi?id=680689 http://www.freedesktop.org/wiki/Software/systemd/inhibit http://lists.freedesktop.org/archives/systemd-devel/2012-September/006604.html
Since I already got my hands into the mate-power-manager code, I am happy to investigate the best way to handle this. Either a runtime flag, or a build switch perhaps to disable mate-power-managers interactions with the hardware switches. Should we also wrap the systemd apis, so that we can change the systemd sleep options from the mate-power-manager gui?
My suggestion would be to simply disable/inhibit the systemd functions what mate-power-manager handles via the api(s) mentioned above, and be done with it.
I have had a look, and I agree, these apis seem pretty easy to use. A bit of a "practical" question for writing the fix to this. My thought is that this should go into gpm-manager.c. When the manager is created, we set the inhibitor, when it's destroyed, it's removed. Does that sound reasonable?
reasonable +1
Fixed upstream https://github.com/mate-desktop/mate-power-manager/pull/37
mate-power-manager-1.5.1-2.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/mate-power-manager-1.5.1-2.fc18
mate-power-manager-1.5.1-2.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/mate-power-manager-1.5.1-2.fc17
mate-power-manager-1.5.1-2.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
mate-power-manager-1.5.1-3.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/mate-power-manager-1.5.1-3.fc17
mate-power-manager-1.5.1-3.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.