I was recently facing some troubles on my notebook, concerning KDEs PowerDevil cooperating with logind, the power-manager delivered by systemd, which always put my notebook into standby, also when deactivated in KDE Power Settings.
Connecting logind with other power-managers
Some words to the basic architecture of loginds power-management: logind has some features to control the power-saving features of modern computers. All this works out of the box and without the need of a additional power-manager. If you now use one of these additional power-managers, there are basically two different approaches, how those managers interact with logind:
- by disabling loginds powermanagement completely, the power-manager can directly communicate via d-bus or acpi and set its actions.
- by calling so called “inherited commands” provided by systemd. I want to dig a little bit deeper into this mode, due to it’s most used in newer desktop environments.
Basically, system events like a closed lid or a (dis)connected power chord are transported to the power-managers via multiple busses. in this case, logind sets a timeout, on how long a other managers got time to react on this event, before systemd does. KDE (and most others like GNOME, etc.) exactly do this and call the logind “inherited commands”. Systemd then still sets the actions by it self, but does what the other power-manager wants. Seems legit? Yes, but now we come to the point of failure.
Problems with logind default settings
On my notebook (Gigabyte P35GV2) i set-up KDE power-management to do nothing, if my notebook is on AC and the lid is closed. But even then, the system entered standby, stopping all downloads, services, etc… Like i wrote before, digging into systemds architecture brought me to logind, which has the following setting:
In Arch Linux, this file has nothing set, it’s just a list of loginds settings with their default values. The sixth setting shows the timeout for the inhibited commands, before systemd does its own way, followed by the settings on which actions systemd takes. Systemd even manages the docked state of a notebook. The next switches are “*IgnoreInhibited” which controls the role of systemd when another power-manager inhibits logind. This is the failure. Systemds default setting on “LidSwitchIgnoreInhibited” is yes, which means logind ignores the inhibited command on a lid switch event and does the routine according to its own settings.
By removing the comment (remove #) on “LidSwitchIgnoreInhibited” and changing this value to no, the frontend power-manager has the complete control over the lid switch actions.
In Arch with KDE/Plasma 5, this solved the problem for me, i think it would also solve it with GNOME or Cinnamon (which i used before). If you run into this problem and try this fix, let me (and others) know in the comments if this also works for other desktop environments!