Regression: patch to bug 539477 breaks Super+P keybindings

I applied the workaround in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/539477/comments/64 to make super+p work again in Maverick at the expense of breaking the Gnome monitor settings GUI.

For those suffering, possible workarounds to the breakage the workaround causes are: a) to change monitor settings with the Gnome control panel, temporarily undo the workaround; or b) drive xrandr from the command line or use the arandr GUI front-end to xrandr instead of the Gnome GUI.

Thank you for your bug report but it seems there is no way to deal with those broken bios configuration without breaking the keybindings, you should probably set a new binding

This should at least be configurable.

What happens when some other laptop has a special key that maps to some other keyboard shortcut I use?

I'm also having this problem. Whilst I accept it's great that Ubuntu is trying to work better on laptops etc., this should be configurable in Keyboard Shortcuts. Currently I have Win+P set there for playing music, but this totally overrides that, and there's no notification of that conflict.

In effect, there seem to be 2 applications setting keyboard shortcuts which effectively conflict with one another - why not unify them?

I ran into this problem and came up with a workaround using xsession and xbindkeys, see http://blog.n01se.net/?p=314

Fix for bug 539477 broke my usage of Mod4-P (incidentally, on a Lenovo laptop). What's the reason for the "Won't Fix" status here?

This is extremely unexpected and annoying behavior. Stealing existing user shortcuts and making them not configurable is unacceptable. Just because some Dell/HP laptops have a certain behavior is not a valid reason for having one of your most heavily used shortcuts in your IDE do something else all of a sudden. Also consider it unacceptable to be asked to change my existing, heavily day-to-day used shortcuts.

What is the argument for not making this configurable?

If I know that I am not affected by that BIOS bug it would be nice if I could turn off this "feature" without having to apply a patch and recompile every time a new version comes out.

Hello there.

Please reopen this: silently breaking things is bad, even if it fixes some other things. This keybinding should at least be visible in Keyboard Shortcuts prefs.

Suggested interface: If the user has bound <Super>p to anything in compiz, then this requested behavior should override the screen-switching behavior.

However, when the user makes such a binding, an "Are you sure?" dialog box should pop up, warning that this may break the screen-switching key on some laptops. This resembles the way compiz handles key binding conflicts between different plugins.

If the user clears the binding, then the screen-switching behavior should show through again.

Users should be able to bind <Super>p to whatever they want in any application. Compiz should not be the only one allowed to override this Dell/HP specific misguided choice for their screen configuration wizard.

Wonky hardware makes a compelling case for monitor switching to be the default behavior.

It does not present a compelling case for making this behavior non-configurable. This is especially the case since this exact shortcut is obviously used by quite a few users.

I just wasted a bunch more time because of this bug. The xrandr plugin to gnome-settings-daemon is now configured in dconf not in gconf: http://askubuntu.com/questions/68463/how-to-disable-global-super-p-shortcut
Because there's no option to stop the keybinding being stolen, one still has to disable it entirely.

Correction: one now needs to disable the media keys plugin instead of the xrandr plugin (using dconf) to prevent <super>p being stolen. This new fix breaks different things to before. For my machine I've recompiled gnome-settings-daemon to get rid of the problem. If anyone else wants to do the same, the offending shortcut is in acme.h, search for VIDEO_OUT_KEY.

[Finding this file reminded me that media key handling used to be in a standalone program called acme. It's a shame that gnome moved away from providing simple standalone programs that could be taken in isolation.]

@Iain can you be more specific in describing your solution? I downloaded the source to gnome-settings-daemon but do not see acme.h:

/tmp/gnome-settings-daemon-2.32.1$ grep -R VIDEO *
plugins/xrandr/gsd-xrandr-manager.c:#define VIDEO_KEYSYM "XF86Display"
plugins/xrandr/gsd-xrandr-manager.c: manager->priv->switch_video_mode_keycode = get_keycode_for_keysym_name (VIDEO_KEYSYM);

This is *really* annoying and confusing.

Mod+p is a standard binding in xmonad. Mod4 is the common choice for Mod. Why should I have to change my xmonad configuration because some feature I don't care about or use wants that binding? And at minimum, why can't I disable this binding?

@Vinh sorry I didn't see your request. I have a later version than you, 3.2.2. If you have an earlier Ubuntu release, maybe try the work-around I linked to in the first comment?

The good news is that this issue may have been fixed in Ubuntu "precise" 12.04. I just installed that on a new machine and I don't seem to have the issue. Although the offending code still seems to be there, so I'm not sure what's going on. I don't currently have the time to upgrade the machines that had the issue before.

BTW in gnome-settings-daemon 3.4.2, which comes with Ubuntu 12.04, acme.h got renamed shortcuts-list.h

Precise 12.04, and this hit me badly. Interestingly enough, doesnt happen when xinerama is turned on. But then again, gnome-settings-daemon crashes with xinerama on.

Why is this not fixed if all it takes is to remove a horribly written patch?

Precise 12.04 still has this behaviour.

Basically, right now there are only two very ugly fixes: either turn off xrandr support or media-keys. The first is unacceptable if you use multiple monitors (me) and the second if you use media keys (me). So someone that needs both (me) has a big problem.

This forced shortcut caused me a ton of troubles and wasted time. Just because there is broken hardware out there does not mean you should force a broken fix down everyone's throat.

Please someone revert this horrible patch.

In case someone wants to know how to disable xrandr | media keys:
1) install dconf-editor
2) uncheck "activate" in org -> gnome -> settings-daemon -> plugins -> media-keys | xrandr

You could also probably just remove the «video-out» shortcut key who is mapped on «super+p».

These hotkeys configurations should probably be easier to configure from some settings panel as «super+p» is used in IDE's for example. Another example is that «super+p» is often used in xmonad for spawning dmenu as «most» users remap xmonad's modifier key to super.

This was tested and confirmed to work in Debian Wheezy, since I got the tip from this bug report and post #18
to dig into dconf-editor and check org->gnome->settings-daemon->plugins->media-keys.

I guess this also works for Ubuntu users and I highly suggest this setting to be easily configurable thru «control panel» or wherever you configure hotkeys in Ubuntu for usability. :-)

I also support others that this shouldn't be the default behavior to override «super+p» globally due to hardware vendors doing silly stuff.

And for those poor users with silly hardware, the «control panel» should warn their users that video-out sadly has to be mapped to «super+p» to work if the keycode is hardcoded by the vendor.

I don't understand why bug #539477 has been fixed at the cost of an unknown but definitely unaffected majority of users who don't use hardware that implemented strange Microsoft standards.

I hope it's possible to revert the fix for #539477 and commit a new fix that is less intervening. What about adding an option to the keyboard settings in Gnome Control Center?

Since I extensively use <Super> in combination with several keys (read: letters), "p" being only one out of many, I patched gnome-settings-daemon by removing the <Super>p shortcut, and created my own deb package.

Though I could refrain from using <Super>p, I can't prevent my fingers from accidentally hitting said shortcut.

Turning off xrandr, turns off the ability to switch properly monitors even through Settings. Please either unbind mod4+p or give a proper workaround.

As I posted on the upstream bug, this bug would be a lot less annoying if:

1. The key short were listed in the Keyboard configuration applet, with
appropriate greying out/some sort of explanatory message that comes up if you
try to change it.

2. The workaround were only applied on machines that need it.

There are many good suggestions here -- what are the next steps required in order for action to happen (at least in Ubuntu)? Is someone willing to create and attach a patch to this bug?

My workaround (14.10) to use the <Super>p keybinding as screenshot shortcut is to unbind unity/compiz bindings and add this to $HOME/.xbindkeysrc

"gnome-screenshot -c"
mod4 + p

This keeps xrandr and other media keys 'alive'. See also:
http://askubuntu.com/a/585204/209676

I have this problem on a new 16.04 install.

Gnome bug 651571 was marked as a dupe of 792892; updating remote watch accordingly.