After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 755953 - No longer to customize power-button action and systemd defaults are ignored
No longer to customize power-button action and systemd defaults are ignored
Status: RESOLVED FIXED
Product: gnome-settings-daemon
Classification: Core
Component: media-keys
3.18.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-settings-daemon-maint
gnome-settings-daemon-maint
: 756481 (view as bug list)
Depends on: 756116
Blocks:
 
 
Reported: 2015-10-01 17:42 UTC by Phillip Wood
Modified: 2017-04-27 08:21 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Stop handling power keys (8.36 KB, patch)
2015-10-06 10:25 UTC, Phillip Wood
none Details | Review
Stop handling power keys (9.73 KB, patch)
2015-10-07 10:05 UTC, Phillip Wood
rejected Details | Review

Description Phillip Wood 2015-10-01 17:42:02 UTC
I used to use the 'power-button' dconf setting to hibernate my desktop when I pressed the power button. Commit 50564cde49ca2 (bug 753713) removed this functionality. The commit message says that these buttons should work as advertised out of the box - that's sensible but it's not clear that they didn't, after all the schema has default values. Now pressing my power button suspends the computer - I've no idea why. What's really annoying is that it is easy to configure this with a simple edit to /etc/systemd/logind.conf but as far as I can tell gnome-settings-daemon overrides those settings.
Comment 1 Phillip Wood 2015-10-06 10:25:28 UTC
Created attachment 312719 [details] [review]
Stop handling power keys

gsd no-longer facilitates users overriding power key actions, and
overrides the system default actions specified in
/etc/systemd/logind.conf. This means that users are expected to write
custom udev rules if they want to have custom power key actions while
running GNOME. This is rather unfriendly and considerably more effort
than editing logind.conf. As logind sets sensible default actions
there is no need for gsd override the default system actions.
Currently gsd also disables the power keys while the screen is
locked, this patch assumes that functionality will be moved into
gnome-shell.

https://bugzilla.gnome.org/show_bug.cgi?id=756116
Comment 2 Bastien Nocera 2015-10-06 11:19:21 UTC
Review of attachment 312719 [details] [review]:

> gsd

gnome-settings-daemon.

> no-longer

Don't think that's in the OED

> gsd no-longer facilitates users overriding power key actions

And include references about when this happened.

> This is rather unfriendly and considerably more effort than editing logind.conf

I don't like the tone in this sentence.

> this patch assumes that functionality will be moved into gnome-shell.

There's no need for that. The patch won't be applied if the inhibition in the lock screen isn't merged.

::: plugins/media-keys/shortcuts-list.h
@@ -96,3 @@
         { MAGNIFIER_ZOOM_IN_KEY, "magnifier-zoom-in", NULL, NULL, SHELL_ACTION_MODE_ALL },
         { MAGNIFIER_ZOOM_OUT_KEY, "magnifier-zoom-out", NULL, NULL, SHELL_ACTION_MODE_ALL },
-        { POWER_KEY, NULL, N_("Power Off"), "XF86PowerOff", POWER_KEYS_MODE },

Remove those enum members as well.
Comment 3 Phillip Wood 2015-10-07 10:05:34 UTC
(In reply to Bastien Nocera from comment #2)
> Review of attachment 312719 [details] [review] [review]:
> 
> > gsd
> 
> gnome-settings-daemon.
> 
> > no-longer
> 
> Don't think that's in the OED
> 
> > gsd no-longer facilitates users overriding power key actions
> 
> And include references about when this happened.

Done
> > This is rather unfriendly and considerably more effort than editing logind.conf
> 
> I don't like the tone in this sentence.

Sorry I didn't mean to cause offence, I was just trying to explain the motivation for the patch. I've spent several hours searching and experimenting trying to come up with a udev rule that works for the case power switch and failed. It seems much harder than customizing a keyboard (mainly because I've not found any documentation of what to put in the rule - as it's not a keyboard KEYBOARD_KEY_xx=hibernate does not work and nothing else that I've tried has worked).

> > this patch assumes that functionality will be moved into gnome-shell.
> 
> There's no need for that. The patch won't be applied if the inhibition in
> the lock screen isn't merged.

OK I've removed that bit

> ::: plugins/media-keys/shortcuts-list.h
> @@ -96,3 @@
>          { MAGNIFIER_ZOOM_IN_KEY, "magnifier-zoom-in", NULL, NULL,
> SHELL_ACTION_MODE_ALL },
>          { MAGNIFIER_ZOOM_OUT_KEY, "magnifier-zoom-out", NULL, NULL,
> SHELL_ACTION_MODE_ALL },
> -        { POWER_KEY, NULL, N_("Power Off"), "XF86PowerOff", POWER_KEYS_MODE
> },
> 
> Remove those enum members as well.

Done, I'd also missed some power key related #defines in shortcuts-list.h which I've now removed and an extra line in do_action()

I've double checked logind's defaults and the power key turns the power off rather than suspending which while it isn't illogical maybe is a change from gsd's defaults.
Comment 4 Phillip Wood 2015-10-07 10:05:52 UTC
Created attachment 312810 [details] [review]
Stop handling power keys

Since commit 50564cd gsd no longer facilitates users overriding power
key actions and overrides the system default actions specified in
/etc/systemd/logind.conf. This means that users are expected to write
custom udev rules if they want to have custom power key actions while
running GNOME. As logind sets sensible default actions there is no
need for gsd override the default system actions. This means users can
customize power key actions by editing logind.conf rather than having
to write udev rules.

https://bugzilla.gnome.org/show_bug.cgi?id=756116
Comment 5 Bastien Nocera 2015-10-13 09:23:21 UTC
*** Bug 756481 has been marked as a duplicate of this bug. ***
Comment 6 Bastien Nocera 2015-10-13 10:36:31 UTC
(In reply to Phillip Wood from comment #3)
> I've double checked logind's defaults and the power key turns the power off
> rather than suspending which while it isn't illogical maybe is a change from
> gsd's defaults.

That would be a blocker to incorporating this fix. We'll need to find another way to fix this I think.
Comment 7 Phillip Wood 2015-10-19 10:12:18 UTC
(In reply to Bastien Nocera from comment #6)
> (In reply to Phillip Wood from comment #3)
> > I've double checked logind's defaults and the power key turns the power off
> > rather than suspending which while it isn't illogical maybe is a change from
> > gsd's defaults.
> 
> That would be a blocker to incorporating this fix. We'll need to find
> another way to fix this I think.

I thought that would be the case - have you any thoughts on the best way to proceed? Off the top of my head we could

1 - Partially revert commit 50564cd so that it's still possible to customize the power switch but not the suspend and hibernate keys. This assumes most people customize the power switch because they don't have suspend/hibernate keys

2 - Completely revert commit 50564cd

3 - See if the systemd developers would consider changing logind's default action for the power switch

4 - Submit a patch for udev to let the power switch be remapped in the same way as keyboard keys. (I've had a quick grep through the udev sources and as far as I can tell you cannot do this at the moment)
Comment 8 Bastien Nocera 2015-11-02 16:58:53 UTC
I think that following the instructions at the top of http://cgit.freedesktop.org/systemd/systemd/tree/hwdb/60-keyboard.hwdb should work.

evdev:atkbd:dmi:bvn*:bvr*:bd*:svn*:pn*
 KEYBOARD_KEY_e05e=sleep                                   # Map power to KEY_SLEEP (hibernate)

I'm not certain of the scancode to use, but that's a good first step. Let me know how it works out.
Comment 9 Bastien Nocera 2015-11-04 14:26:15 UTC
So, I've thought about this more, and yes, we probably shouldn't have dropped the configuration setting for the power key itself. But as we have, let's see whether we can fix this in a way that doesn't require us to re-add a setting.

We already have bug 755165 about making the power "button" shut down in VMs. I'm fairly certain that's the only use case for making it possible to shutdown the machine from the button (or really, the menu item in the VM interface).

I've asked two commenters in bug 753713 why they preferred the interactive dialogue.

Philip, about your use of hibernation, would it be enough to always hibernate if hibernation is supported on the machine?
Comment 10 Phillip Wood 2015-11-04 15:03:12 UTC
(In reply to Bastien Nocera from comment #8)
> I think that following the instructions at the top of
> http://cgit.freedesktop.org/systemd/systemd/tree/hwdb/60-keyboard.hwdb
> should work.
> 
> evdev:atkbd:dmi:bvn*:bvr*:bd*:svn*:pn*
>  KEYBOARD_KEY_e05e=sleep                                   # Map power to
> KEY_SLEEP (hibernate)
> 
> I'm not certain of the scancode to use, but that's a good first step. Let me
> know how it works out.

Thanks for the suggestion, that's what I've been trying to get to work but as you say finding the correct scancode is tricky. I can remap the keyboard using this. With the keyboard evtest shows the scancode and key events. With the power button on the case evtest only shows the key event, there is no scancode event. I'm not sure whether this means there is no scancode for simple buttons. Looking in the logs I get messages like
systemd-udevd[4620]: Error calling EVIOCSKEYCODE on device node '/dev/input/event0' (scan code 0xe05e, key code 142): Invalid argument
I tried creating a file with remapping all the scancodes from 0-0xffff but the button is still not remapped. I only get about a thousand error messages about invalid scancodes though so I'm not sure what happened to the other 50000
Comment 11 Phillip Wood 2015-11-04 15:04:52 UTC
(In reply to Bastien Nocera from comment #9)
> 
> Philip, about your use of hibernation, would it be enough to always
> hibernate if hibernation is supported on the machine?
Yes that would be fine for me, though I can see other people wanting the machine to suspend when they press the power button.
Comment 12 Bastien Nocera 2015-11-04 15:16:10 UTC
(In reply to Phillip Wood from comment #10)
<snip>
> Thanks for the suggestion, that's what I've been trying to get to work but
> as you say finding the correct scancode is tricky. I can remap the keyboard
> using this.

Can, or can't? If it doesn't work, it's probably because that power button is emitted through ACPI, not through as other keyboard keys would be.

Let's move on from that and discuss comment 9.
Comment 13 Phillip Wood 2015-11-04 17:44:36 UTC
(In reply to Phillip Wood from comment #11)
> (In reply to Bastien Nocera from comment #9)
> > 
> > Philip, about your use of hibernation, would it be enough to always
> > hibernate if hibernation is supported on the machine?
> Yes that would be fine for me, though I can see other people wanting the
> machine to suspend when they press the power button.

I think you're right about the VM case being the only time you'd want to shut down. On a laptop you can always suspend by closing the lid but not all laptops have a hibernate button. On a desktop you don't have a suspend or hibernate button, only a power button so I'm having difficulty in imagining how we can support users who want to suspend when they press the power button and those that want to hibernate without some kind of configuration option. 

On the (surprisingly low blood pressure) reddit thread mentioned on bug 753713 one user mentions that on their macbook the power button is so close to backspace that they now sometimes accidentally suspend the computer when they want to delete some text. They don't explicitly say what customization they used but presumably they previously had the power button disabled so there might be a use case for that as well.
Comment 14 Bastien Nocera 2015-11-04 18:04:16 UTC
(In reply to Phillip Wood from comment #13)
> (In reply to Phillip Wood from comment #11)
> > (In reply to Bastien Nocera from comment #9)
> > > 
> > > Philip, about your use of hibernation, would it be enough to always
> > > hibernate if hibernation is supported on the machine?
> > Yes that would be fine for me, though I can see other people wanting the
> > machine to suspend when they press the power button.
> 
> I think you're right about the VM case being the only time you'd want to
> shut down. On a laptop you can always suspend by closing the lid but not all
> laptops have a hibernate button.

Newer ones can have Hybrid Sleep, so you'd only need to suspend, and the firmware would take care of the rest, but that's only a small portion of laptops. In the end, it would be the same problem as with desktops (see below).

> On a desktop you don't have a suspend or
> hibernate button, only a power button so I'm having difficulty in imagining
> how we can support users who want to suspend when they press the power
> button and those that want to hibernate without some kind of configuration
> option. 

If we could detect long presses on those machines, we could always hibernate (if available) or suspend on a short press, and offer power off on a long press. But I think that they're synthetised by the ACPI layer. I'm checking up on that now.

> On the (surprisingly low blood pressure) reddit thread mentioned on bug
> 753713 one user mentions that on their macbook the power button is so close
> to backspace that they now sometimes accidentally suspend the computer when
> they want to delete some text. They don't explicitly say what customization
> they used but presumably they previously had the power button disabled so
> there might be a use case for that as well.

Probably something to allow in GSettings but not show in any UI we might have.

So, if we could detect long presses, we could only have a single setting to allow the power button to be disabled. Might even be considered a lockdown setting.

I should hopefully have an answer on that shortly.
Comment 15 Lyude 2015-11-06 17:57:43 UTC
Hi! This is something I was disappointed to see not working, so I figured I'd give some insight into the use cases for this as someone who actually uses this. I've never actually used the power button for suspend, I've set it to shut down on basically every machine I've owned in the last 6 years. For suspend I usually just close the lid of my laptop, or let my machine just idle itself into suspend. Since I do driver development, I also have to switch between various laptops and machines constantly, reconfigure things, etc. While I could go into the menu and shut down each machine every time, it's unnecessary tedious when there's a button I'd expect to do just that for me.

In addition to that, it should be mentioned that this could very well cause issues for users who have keyboards with explicit power buttons on them, since now they don't have their intended behavior (they don't by default anyhow, but we should at least give the user the ability to make it work properly).

Anyway; re: detecting long presses; as far as actual laptop power buttons go this is definitely something I'd avoid trying to rely on. On this T440s I've got in front of me, the power button just sends a simultaneous press/release event through it's evdev node, regardless of how long you hold it. On top of that, you actually have to press the power buttons on the latest few lines of ThinkPads for at least 1-2 seconds before it even registers any events (presumably to stop users from hitting their power buttons by accident). This only applies while the machine is on though, if the machine is off the power button is instant. Plus, if a user tries to do a long press they could accidentally force their machine off.

Another point I'd like to make: the Macbook mentioned in that reddit thread is definitely not the only laptop where is this an issue. We've got multiple laptops in the office here from multiple manufacturers where the power key is actually part of the keyboard layout. In fact, on the Chromebook pixel it's actually placed as a normal keyboard key to the right of the volume up key in the top right corner.
Comment 16 Lyude 2015-11-06 18:12:45 UTC
Small update here: Just tested the events the acpi drivers send for the power button with an Asus N550JK and an HP Elitebook. Both of them send an immediate press/release for the power button also.
Comment 17 Bastien Nocera 2015-11-09 16:23:14 UTC
(In reply to Lyude from comment #16)
> Small update here: Just tested the events the acpi drivers send for the
> power button with an Asus N550JK and an HP Elitebook. Both of them send an
> immediate press/release for the power button also.

Yes, I figure that out, and I was pointed to the (huge) ACPI spec which says it's impossible to handle. We could, however, handle that for soft-non-ACPI power keys, such as the ones found on keyboards and tablets. That'd be bug 657496.

So far, I have implemented:
- VMs will always power off
- tablets will always suspend (if the tablet can't suspend, best fix that, or run a custom g-s-d[1])
- for laptops and desktops, I want to allow choosing the action, which would mean adding a UI for it. So far, possible actions would be "suspend" (default), "hibernate" and "nothing".

I'm still waiting for an answer on why the "interactive" might be useful for this case.

[1]: And I do have one of those sorts of tablets as well...
Comment 18 Lyude 2015-11-09 18:00:46 UTC
(In reply to Bastien Nocera from comment #17)
> (In reply to Lyude from comment #16)
> > Small update here: Just tested the events the acpi drivers send for the
> > power button with an Asus N550JK and an HP Elitebook. Both of them send an
> > immediate press/release for the power button also.
> 
> Yes, I figure that out, and I was pointed to the (huge) ACPI spec which says
> it's impossible to handle. We could, however, handle that for soft-non-ACPI
> power keys, such as the ones found on keyboards and tablets. That'd be bug
> 657496.
> 
> So far, I have implemented:
> - VMs will always power off
> - tablets will always suspend (if the tablet can't suspend, best fix that,
> or run a custom g-s-d[1])
> - for laptops and desktops, I want to allow choosing the action, which would
> mean adding a UI for it. So far, possible actions would be "suspend"
> (default), "hibernate" and "nothing".
What is the point of removing the shutdown option here though? This would confuse a lot of users coming from operating systems where this is a valid function for the power button, along with all of the existing gnome users.
> 
> I'm still waiting for an answer on why the "interactive" might be useful for
> this case.
> 
> [1]: And I do have one of those sorts of tablets as well...
Comment 19 Bastien Nocera 2015-11-09 18:17:42 UTC
(In reply to Lyude from comment #18)
<snip>
> What is the point of removing the shutdown option here though? This would
> confuse a lot of users coming from operating systems where this is a valid
> function for the power button, along with all of the existing gnome users.

We're talking from a clean slate perspective, so, as far as this discussion is concerned, this isn't an existing option. Best tell me what your use case for this would be instead.
Comment 20 Lyude 2015-11-09 18:26:09 UTC
(In reply to Bastien Nocera from comment #19)
> (In reply to Lyude from comment #18)
> <snip>
> > What is the point of removing the shutdown option here though? This would
> > confuse a lot of users coming from operating systems where this is a valid
> > function for the power button, along with all of the existing gnome users.
> 
> We're talking from a clean slate perspective, so, as far as this discussion
> is concerned, this isn't an existing option. Best tell me what your use case
> for this would be instead.

Hi, it was the use case I mentioned in the first comment I made on here. When you're working on something where you can expect to have to power cycle the computer frequently, e.g. changing bios settings, switching between different operating systems to test things, etc. It's convenient to be able to just shut down the computer by pressing the button once instead of having to go through menus and find the shutdown button every time. This is something I do daily when I'm working on kernel drivers, trying to reproduce bugs, etc.
Comment 21 Bastien Nocera 2015-11-10 11:45:23 UTC
(In reply to Lyude from comment #20)
> (In reply to Bastien Nocera from comment #19)
> > (In reply to Lyude from comment #18)
> > <snip>
> > > What is the point of removing the shutdown option here though? This would
> > > confuse a lot of users coming from operating systems where this is a valid
> > > function for the power button, along with all of the existing gnome users.
> > 
> > We're talking from a clean slate perspective, so, as far as this discussion
> > is concerned, this isn't an existing option. Best tell me what your use case
> > for this would be instead.
> 
> Hi, it was the use case I mentioned in the first comment I made on here.
> When you're working on something where you can expect to have to power cycle
> the computer frequently, e.g. changing bios settings, switching between
> different operating systems to test things, etc.

In which case you'd want "reboot" not "power off".

> It's convenient to be able
> to just shut down the computer by pressing the button once instead of having
> to go through menus and find the shutdown button every time.

If you were logged in remotely for example, to debug, you'd probably want the command not to block because of that, but the code we use right now would, asking you to enter a password.

It would also mean, for those setups, a particularly bad default, closing apps with opened files, etc.

> This is
> something I do daily when I'm working on kernel drivers, trying to reproduce
> bugs, etc.

Wouldn't this be better served by a custom keyboard shortcut, which could bypass password prompts to force a reboot? I would think it would be, from my own experience hacking drivers (look me up in the kernel log ;)
Comment 22 Bastien Nocera 2015-11-10 13:03:55 UTC
commit 8c403d8ac4c087947ebc2c8a7cca17b9a1ae4698
Author: Bastien Nocera <hadess@hadess.net>
Date:   Tue Nov 10 12:54:16 2015 +0100

    media-keys: Suspend when power key is pressed on tablets
    
    https://bugzilla.gnome.org/show_bug.cgi?id=755953

commit 329594958f94f3917f30ecc581419b1392839e12
Author: Bastien Nocera <hadess@hadess.net>
Date:   Wed Nov 4 16:01:57 2015 +0100

    media-keys: Shutdown when power key is pressed in VM
    
    https://bugzilla.gnome.org/show_bug.cgi?id=755165

commit 69d9d8b1eda2d50acca5b4da58003afb8b82a7f1
Author: Bastien Nocera <hadess@hadess.net>
Date:   Wed Nov 4 13:39:09 2015 +0100

    media-keys: Re-add configuration for the power button
    
    In commit 50564cde49ca2e17fb7e59f36a35d61c2cbef1af, we removed support
    for configuring the various "sleep state" buttons. However, the power
    button might need different behaviour based on the machine, which we
    cannot always detect.
    
    In later commits, we'll hard-code the actions for tablets and virtual
    machines. Note that "power off" is not an option as this would make
    the default action too destructive. It is recommended that you use a
    custom shortcut for this instead.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=755953

See https://bugzilla.gnome.org/show_bug.cgi?id=757880 for the UI we'll provide in GNOME 3.20.
Comment 23 Lyude 2015-11-10 13:17:52 UTC
(In reply to Bastien Nocera from comment #21)
> (In reply to Lyude from comment #20)
> > (In reply to Bastien Nocera from comment #19)
> > > (In reply to Lyude from comment #18)
> > > <snip>
> > > > What is the point of removing the shutdown option here though? This would
> > > > confuse a lot of users coming from operating systems where this is a valid
> > > > function for the power button, along with all of the existing gnome users.
> > > 
> > > We're talking from a clean slate perspective, so, as far as this discussion
> > > is concerned, this isn't an existing option. Best tell me what your use case
> > > for this would be instead.
> > 
> > Hi, it was the use case I mentioned in the first comment I made on here.
> > When you're working on something where you can expect to have to power cycle
> > the computer frequently, e.g. changing bios settings, switching between
> > different operating systems to test things, etc.
> 
> In which case you'd want "reboot" not "power off".
No. In this case I want "power off" because I'm going to be shutting down the machine and moving my hard drive to a different machine for testing.
> 
> > It's convenient to be able
> > to just shut down the computer by pressing the button once instead of having
> > to go through menus and find the shutdown button every time.
> 
> If you were logged in remotely for example, to debug, you'd probably want
> the command not to block because of that, but the code we use right now
> would, asking you to enter a password.
> 
> It would also mean, for those setups, a particularly bad default, closing
> apps with opened files, etc.
> 
> > This is
> > something I do daily when I'm working on kernel drivers, trying to reproduce
> > bugs, etc.
> 
> Wouldn't this be better served by a custom keyboard shortcut, which could
> bypass password prompts to force a reboot? I would think it would be, from
> my own experience hacking drivers (look me up in the kernel log ;)

No, modifying and maintaining a patch to my kernel just to fix this surprisingly doesn't sound like a reasonable option to me.
Comment 24 Bastien Nocera 2015-11-10 13:21:08 UTC
(In reply to Lyude from comment #23)
<snip>
> > Wouldn't this be better served by a custom keyboard shortcut, which could
> > bypass password prompts to force a reboot? I would think it would be, from
> > my own experience hacking drivers (look me up in the kernel log ;)
> 
> No, modifying and maintaining a patch to my kernel just to fix this
> surprisingly doesn't sound like a reasonable option to me.

Huh, we have custom shortcuts in the keyboard panel. No need to hack the kernel there.
Comment 25 Lyude 2015-11-10 13:32:05 UTC
(In reply to Bastien Nocera from comment #24)
> (In reply to Lyude from comment #23)
> <snip>
> > > Wouldn't this be better served by a custom keyboard shortcut, which could
> > > bypass password prompts to force a reboot? I would think it would be, from
> > > my own experience hacking drivers (look me up in the kernel log ;)
> > 
> > No, modifying and maintaining a patch to my kernel just to fix this
> > surprisingly doesn't sound like a reasonable option to me.
> 
> Huh, we have custom shortcuts in the keyboard panel. No need to hack the
> kernel there.

Rereading that message I misinterpreted you, I completely forgot about the custom shortcuts. Sorry about that! I guess that is a reasonable workaround.

Still though, I really don't agree with the idea of just outright removing this feature. Numerous laptops have explicit suspend buttons, some even have explicit hibernate buttons. While I'm not advocating for power off to ever be the default in this case (I agree with you, that is too destructive), if a user already has a button dedicated to suspending their laptop it seems perfectly reasonable they might want their power button to just shut the machine down. Otherwise they've just got two suspend buttons, and unless they want one button to do hibernate there isn't much use in that. This doesn't look like a difficult feature to maintain either judging by the patches.
Comment 26 Bastien Nocera 2015-11-10 16:50:31 UTC
I'm not really a fan of offering more customisation than is really necessary. In this case, this is something that'll likely come back to bite us (me...) in the arse, when we offer the setting in the Power settings.

I'd rather leave it at that, and let me know whether you feel the same way in a couple of months ;)
Comment 27 Philippe L. 2016-04-23 09:36:59 UTC
I think I'm a bit late to the party (the perks of running Gnome on Ubuntu, always 6 months late at best), but my reasons for wanting interactive to be the behaviour of the power-button are the following:

- Since the power key is located on the keyboard, right above the backspace key, I sometimes click it by mistake, which in the current state of things would either suspend or hibernate the machine (or do nothing). In the best case scenario it would be a minor issue, but still one (having to wake up the device), but to top that off, on my laptop hibernate isn't supported at all and suspend only works sometimes. That means that unless I set the power button to do nothing, I will frequently have to hard shutdown the device when I do click the power button by mistake, which isn't ideal. Having it set to interactive had the benefits of putting a safenet, as I could then just click escape and keep on going.

- I just empirically prefer having access to the interactive menu at the litteral touch of a button. I think it's just more intuitive than having to navigate to the option in the panel with the mouse. Granted, that's an opinion and not an argument, but still.

My current workaround is to have the power button set to nothing, and have CTRL+Power-button remapped to the interactive menu, as remapping power-button alone doesn't seem to work. It's a decent workaround, but I do think the option to just set it to interactive, maybe just in gsettings and not in the Tweak Tool, might be a good addition.
Comment 28 Rune Langelund 2016-04-23 10:15:41 UTC
Another Gnome Ubuntu user joining in 6 months to late, having the same issue with the power button alone is doesn't function in remap. 

I like the interactive menu, it makes sure that if I hit my power button by random I get 60 seconds to react before my system just shuts down, where as the shut-down just kills it, at this point I can't get my power button to do either of those things, but having at least one of those two options is important to me.
Comment 29 Bastien Nocera 2016-04-23 12:17:57 UTC
The bug is fixed in 3.18 for the backend parts, and there's UI for it in the Power panel in 3.20.

(In reply to Philippe L. from comment #27)
<snip>
> My current workaround is to have the power button set to nothing, and have
> CTRL+Power-button remapped to the interactive menu

That's pretty much how we expected other use cases to be covered.
Comment 30 Philippe L. 2016-04-23 13:14:57 UTC
(In reply to Bastien Nocera from comment #29)
> The bug is fixed in 3.18 for the backend parts, and there's UI for it in the
> Power panel in 3.20.

Do you mean that interactive is an option too in 3.18 and 3.20? It doesn't seem to be one, in dconf, in 3.18. Is there another way to enable it?
 

> > My current workaround is to have the power button set to nothing, and have
> > CTRL+Power-button remapped to the interactive menu
> 
> That's pretty much how we expected other use cases to be covered.

It's a good workaround, but the fact that mapping power-button itself doesn't seem to be possible is a drawback there. It still works, but it's not really seamless.
Comment 31 Rune Langelund 2016-04-23 16:26:44 UTC
Installed debian testing with gnome 3.20 and the issue is fixed there, so I'm happy.
Thanks for the help.
Comment 32 Rune Langelund 2016-05-17 06:21:05 UTC
(In reply to Rune Langelund from comment #31)
> Installed debian testing with gnome 3.20 and the issue is fixed there, so
> I'm happy.
> Thanks for the help.

Edit: running 3.14**
Comment 33 Alexander Korsunsky 2016-11-29 14:59:17 UTC
(In reply to Philippe L. from comment #27)
> I think I'm a bit late to the party (the perks of running Gnome on Ubuntu,
> always 6 months late at best), but my reasons for wanting interactive to be
> the behaviour of the power-button are the following:
>
> ...
> 
> - I just empirically prefer having access to the interactive menu at the
> litteral touch of a button. I think it's just more intuitive than having to
> navigate to the option in the panel with the mouse. Granted, that's an
> opinion and not an argument, but still.

Even later to the party, but I agree with Philippe here.

Would it be possible to implement the "interactive" option back into it?

I tried to bind the Power Button to the logout dialog, but the gnome shortcut selection does not capture power button presses.

Should I create a new report for that?
Comment 34 Michael Catanzaro 2016-11-29 15:09:08 UTC
(In reply to Alexander Korsunsky from comment #33)
> Would it be possible to implement the "interactive" option back into it?

See bug #771552 for the backend portion of this, which is used in Endless. Configuration UI would be an issue for gnome-control-center, though.
Comment 35 Alexander Korsunsky 2016-11-29 15:24:03 UTC
> See bug #771552 for the backend portion of this, which is used in Endless.
> Configuration UI would be an issue for gnome-control-center, though.

Would it? Looks to me like it could be as simple as adding back in the 'interactive' option, like in this patch from openSUSE:

https://build.opensuse.org/package/view_file/openSUSE:Factory:Staging:G:DVD/gnome-settings-daemon/gnome-settings-daemon-more-power-button-actions.patch?expand=1


I checked in the gnome-settings-daemon repository on GitHub and it seems like the handling code is alive and well:

https://github.com/GNOME/gnome-settings-daemon/blob/21fb652101fbf81d16f76178da9614dcd547686a/plugins/media-keys/gsd-media-keys-manager.c#L1912
Comment 36 Michael Catanzaro 2016-11-29 17:18:46 UTC
(In reply to Alexander Korsunsky from comment #35)
> > See bug #771552 for the backend portion of this, which is used in Endless.
> > Configuration UI would be an issue for gnome-control-center, though.
> 
> Would it? Looks to me like it could be as simple as adding back in the
> 'interactive' option, like in this patch from openSUSE:
> 
> https://build.opensuse.org/package/view_file/openSUSE:Factory:Staging:G:DVD/
> gnome-settings-daemon/gnome-settings-daemon-more-power-button-actions.
> patch?expand=1

Yeah, that's actually what you want, my patch is related but different.
Comment 37 Morse 2017-04-25 11:14:42 UTC
(In reply to Bastien Nocera from comment #26)
> I'm not really a fan of offering more customisation than is really
> necessary. In this case, this is something that'll likely come back to bite
> us (me...) in the arse, when we offer the setting in the Power settings.
> 
> I'd rather leave it at that, and let me know whether you feel the same way
> in a couple of months ;)

Hi. So, I'm not sure if my opinion will change anything, but I was really suffering with this decision for all this time, to the point that I'm considering to starting my own copr repository to just add back the "shutdown" option.

And one simple reason why I don't use suspend: it doesn't work on my elitebook 8760w. Or to be more precise, it rarely works. Something got broken in it, presumably on the hardware level, so now 9 out of 10 suspends end in "hardware error" state, and I have to do a power shut down with 5-second button press, which I don't think is very healthy for my laptop. So I would really love the customized option, other than "patch and recompile g-s-d".
Comment 38 Alexander Korsunsky 2017-04-25 11:42:11 UTC
I believe the GNOME maintainers have stopped reading this bug a while ago. Something about "Resolved Fixed" might incorrectly indicate that this bug is resolved and fixed.

Should we create a new report for this? Because quite clearly this bug is not fixed.
Comment 39 Morse 2017-04-27 08:21:40 UTC
(In reply to Alexander Korsunsky from comment #38)
> I believe the GNOME maintainers have stopped reading this bug a while ago.
> Something about "Resolved Fixed" might incorrectly indicate that this bug is
> resolved and fixed.
> 
> Should we create a new report for this? Because quite clearly this bug is
> not fixed.

Ok, done. Bug 781817