Similar to https://bugzilla.xfce.org/show_bug.cgi?id=11339, I wanted my system to do a hybrid suspend/hibernate. However, I instead attempted to use 'systemd-logind(8)', by assigning a 'hybrid-sleep' action to the 'HandlePowerKey' event, and making logind ignore inhibit locks on the Power key. Doing it with logind made a bit more sense to me, as it would be independent of the DE environment operating or not. [mark@opy systemd]$ sudo grep -v "^#" logind.conf [Login] HandlePowerKey=hybrid-sleep PowerKeyIgnoreInhibited=yes [mark@opy systemd]$ On my laptops, this seemed to work for a while, however on my desktop, which is the system I most want to use it, it didn't. logind was reporting in the system log that it was receiving a PowerKey event, but wasn't doing anything with it. I thought this may have been a bug with logind, as the description option of PowerKeyIgnoreInhibited=yes sounded like logind should perform actions for these events regardless of if other applications were handling the power button. I lodged a bug a while back about it: https://bugzilla.redhat.com/show_bug.cgi?id=1194951 Lennart Pottering himself got back to me today, and suggested that the DE might be handling the PowerKey, and suggested running the 'systemd-inhibit --list' command. This showed that Xfce4-power-manager was handling the power, hibernate and sleep buttons. This was despite there being no actions attached to those buttons. This seemed to explain why my logind configuration was not working. While there may be a bug with logind's handling of PowerKeyIgnoreInhibited=yes, I think xfce4-power-manager handling buttons that don't have any actions assigned made this issue a bit harder for me to troubleshoot - perhaps on my laptops I had also assigned the 'suspend' action to their power buttons, which made me think this problem was isolated to my desktop. So I think it would be better if xfce4-power-manager only handled buttons for which an action has been assigned, which would allow logind to process buttons without xfc4-power-manager actions. Thanks, Mark.
I've just remembered the other reason I was thinking logind was the better option. It seems that the screen saver is running, it catches the Power button push, and doesn't pass it onto xfce4-power-manager, meaning I can't easily suspend my system with just a power button push when the screen saver is running. The problem I'm trying to solve is to be able to just walk it my study because, for example I'm leaving to go out, and push the Power button to suspend my desktop, without having to switch the screen(s) on, unlock the screen etc.
You should be able to tell xfpm not to inhibit the keys with some xfconf properties, see http://docs.xfce.org/xfce/xfce4-power-manager/faq#how_can_i_make_logind_handle_button_events_instead_of_xfce4-power-manager
Ah, thanks very much Eric for that tip. I'll give it a try. It would seem to me to be more intuitive and obvious for xfce4-power-manager to only handle keys for which it has actions assigned (i.e., don't handle buttons which have "Do nothing" actions). The combinations of behaviours of logind reporting receiving PowerKey events but not doing anything with them, and me not having any events assigned within xfce4-power-manager made this seem more like a bug rather than something I should check the documentation for.
Actually, I could see a use case where somebody might want xfce4-power-manager to handle the Power key but not do anything. So perhaps there needs to be an addition option of "Ignore" i.e. "Do nothing" - handle the Power key, preventing logind from seeing it, but don't do anything. "Ignore" - stop handling the Power key, allowing logind (or something else) to see it
Hmm, that xfconf-query command didn't seem to work. I still get xfce4-power-manager listed as handling the power key, and I still get logind reporting receiving a Power key but doing nothing with it. If I stop xfce4-power-manager completely, then logind hybrid suspends the machine. I also tried changing the 'true' to 'false' on the end of the xfconf-query command, and that didn't work either. -- [mark@opy 15:38:50] xfconf-query -c xfce4-power-manager -p /xfce4-power-manager/handle-power-key -n -t bool -s true [mark@opy 15:38:53] xfce4-power-manager -q [mark@opy 15:38:58] ps -ef | grep power root 2143 1 0 Jun19 ? 00:00:01 /usr/libexec/upowerd mark 27004 24203 0 15:39 pts/21 00:00:00 grep power [mark@opy 15:39:01] systemd-inhibit --list Who: NetworkManager (UID 0/root, PID 1118/NetworkManager) What: sleep Why: NetworkManager needs to turn off networks Mode: delay 1 inhibitors listed. [mark@opy 15:39:17] xfce4-power-manager [mark@opy 15:39:23] systemd-inhibit --list Who: NetworkManager (UID 0/root, PID 1118/NetworkManager) What: sleep Why: NetworkManager needs to turn off networks Mode: delay Who: xfce4-power-manager (UID 1000/mark, PID 27008/xfce4-power-man) What: handle-power-key:handle-suspend-key:handle-hibernate-key:handle-lid-switch Why: xfce4-power-manager handles these events Mode: block 2 inhibitors listed. [mark@opy 15:39:26] --
Oh, right, the code changed before the last stable release. I've corrected the docs, the properties changed to logind-handle-power-key instead of just handle-power-key. Sorry about that. (In reply to Mark Smith from comment #4) > Actually, I could see a use case where somebody might want > xfce4-power-manager to handle the Power key but not do anything. So perhaps > there needs to be an addition option of "Ignore" i.e. > > "Do nothing" - handle the Power key, preventing logind from seeing it, but > don't do anything. > "Ignore" - stop handling the Power key, allowing logind (or something else) > to see it Makes sense to me, I'll bring this up with the other developers. I don't use logind so I'm not entirely sure of all the conflicts between xfpm and logind.
Great, using logind-handle-power-key worked, with logind hybrid suspending my system, including when I had the screen saver locking the screen. I thought to properly test it I would set the Power button action to 'Ask', as a definite way of knowing whether xfce4-power-manager was seeing the Power button event at all with logind-handle-power-key set. It seems that it is, after resuming my system from the hybrid suspend (i.e., logind worked), I was then presented with the 'Ask' dialog box. I'd have thought with logind-handle-power-key set, xfce4-power-manager wouldn't do any processing at all with the Power button event, regardless of what the xfce4-power-manager button assigned action was. For example, if it was set to suspend (because e.g., you ignored the xfce4-power-manager button value because you thought the value didn't matter if logind was going to do the processing), I think you'd get two suspends immediately in a row - one performed by logind, and then once that one was resumed, a second one immediately following, due to xfce4-power-manager processing of the Power button event.
I think that's some of the conflicts between xfpm and logind which might be why the properties were hidden to begin with. But the ignore option (maybe call it something like "System handled") would also allow us to have xfpm do nothing. I'm not sure if that will expose more issues. I know some of the screen lockers do a VT switch and I've heard that confuses logind and causes issues so I'll wait for some of the other maintainers/contributors to chime in.
Agree that 'System handled' is probably better, as it is more descriptive than 'Ignore'. I think my concern about conflicting xfce4-power-manager button assignment values goes away if you're using xfce4-power-manager to determine whether xfce4-power-manager handles the button or not i.e, if Power button is set to 'System handled', then clearly it can't also be set to 'Suspend'.
I cannot comment much on the logind issues as I have never used it, but I'd have no objections against an option like "System handled".
Created attachment 6326 Add a System handled option for the buttons So this patch adds the system handled option. Feel free to test it out when you get a chance. With it, you can either set the logind_handle_power_key to TRUE to always inhibit logind or leave it to FALSE and use the system handled option. This way we don't change existing configurations.
I'm not sure that this option is self-explanatory enough to be just part of that combobox, to be honest. Of course people can just set the option based on trial and error, but whether or not systemd/logind should control this sort of behavior is a decision few can consciously take – you really have to know what systemd is and what it does. That's why I think keeping it a hidden option so that distributors can figure it out for users makes more sense. If users are experienced enough to fiddle with logind policies manually etc, I guess we can expect them to flip a switch in xfconf. My takeaway is that we need to properly document this on docs.xfce.org, so that experienced or power-users can look up what setting to change. My main concern with exposing this would be that people don't understand the option and then we get a lot more bugreports about this... But maybe Sean wants to chip in his 2 cents too, since he wrote that systemd inhibition stuff.
As additional proposal (as discussed on IRC) it would be great if those settings would work like the keyboard settings. That means that there is one big button which either enables or disables the logind-options on a per-user-setting. If enabled, the user can chose the appropriate action from a drop down menu per key. If disabled, everything is greyed out and the drop down shows "system default (<default>)" while "<default>" is read via dbus[1] for the key. The user can than decide if they live with the default or want to change it. [1] http://www.freedesktop.org/wiki/Software/systemd/logind/
I second this proposal, makes sense to me. Especially if we expose logind's settings in the settings dialog, that makes the need for explaining what the "system defaults" are less important.
(In reply to Eric Koegel from comment #11) > Created attachment 6326 > Add a System handled option for the buttons > > So this patch adds the system handled option. Feel free to test it out when > you get a chance. > > With it, you can either set the logind_handle_power_key to TRUE to always > inhibit logind or leave it to FALSE and use the system handled option. This > way we don't change existing configurations. Hi Eric, Is there a quick guide somewhere as to what I need to install etc. to be able to compile xfpm to test this? I've been using the pre-built xfce packages that came with Fedora 22. Thanks, Mark.
(In reply to Simon Steinbeiss from comment #12) > I'm not sure that this option is self-explanatory enough to be just part of > that combobox, to be honest. > > Of course people can just set the option based on trial and error, but > whether or not systemd/logind should control this sort of behavior is a > decision few can consciously take – you really have to know what systemd is > and what it does. That's why I think keeping it a hidden option so that > distributors can figure it out for users makes more sense. > So I think the trouble with the existing "Do Nothing" option is that it actually doesn't literally do nothing - it is preventing logind from performing any actions for the corresponding button. The "Do Nothing" option is doing nothing in the context of xfpm, but not doing nothing in the larger context of the system. I think this is the root cause of my issues. I wanted to use logind to perform these actions because logind should work regardless of what DE is running, whether the screen is locked via a screen saver or even if one isn't running i.e., you're at a console vty. From that perspective, I'd argue that "Do Nothing" is incorrect, as it isn't actually doing nothing with the button event. However, I agree with keeping behaviour the same for an existing action item, which is why having an alternative "System handled" option makes sense to me. Perhaps "System handled (e.g. logind)" might be better, or perhaps have "e.g., systemd-logind(8)" be a hover over popup for that "System handled" option? > If users are experienced enough to fiddle with logind policies manually etc, > I guess we can expect them to flip a switch in xfconf. I don't think people need to fiddle with logind policies, as the logind defaults are what people would expect - from the logind.conf manual page: HandlePowerKey= defaults to "poweroff". HandleSuspendKey= and HandleLidSwitch= default to "suspend". HandleLidSwitchDocked= defaults to "ignore". HandleHibernateKey= defaults to "hibernate". The reason I changed the logind Powerkey option was because I wanted the Power key action to be 'hybrid-sleep' rather than 'poweroff'. > My takeaway is that we need to properly document this on docs.xfce.org, so > that experienced or power-users can look up what setting to change. > So assuming I'm an experienced or power user, the combined behaviour of xfpm "Do Nothing" and logind's reporting of receiving a Powerkey event but not doing anything was quite far from what I expected, such that I immediately thought it was a bug in logind, and lodged it as one. It seemed to me that xfpm would have been literally doing nothing with the Powerkey button, logind was receiving it, but then doing nothing with it, despite what I'd configured in logind.conf to do. > My main concern with exposing this would be that people don't understand the > option and then we get a lot more bugreports about this... > > But maybe Sean wants to chip in his 2 cents too, since he wrote that systemd > inhibition stuff.
Replying to myself, because I forgot some text, > > > My takeaway is that we need to properly document this on docs.xfce.org, so > > that experienced or power-users can look up what setting to change. > > > > So assuming I'm an experienced or power user, the combined behaviour of xfpm > "Do Nothing" and logind's reporting of receiving a Powerkey event but not > doing anything was quite far from what I expected, such that I immediately > thought it was a bug in logind, and lodged it as one. It seemed to me that > xfpm would have been literally doing nothing with the Powerkey button, > logind was receiving it, but then doing nothing with it, despite what I'd > configured in logind.conf to do. > So because the behaviour looked like a bug, because it was quite far from what I expected, I didn't even consider looking up xfpm documentation, because the problem didn't seem to be related to xfpm's behaviour.
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/xfce4-power-manager/-/issues/11. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev