Not going to happen. Windows+P is what Windows uses to cycle through display. That's not why we support it however. The problem is that BIOS vendors, instead of making their "display" key report something useful, made it appear as though "Windows+P" was pressed (sometimes even followed by a Return, to make sure it was taken into account).

That's just crap, but there's a large amount of computers that expect Windows+P to do something within the OS, so we have to support it.

Please, if you are going to refuse to include the patch for some reason, at least be honest and take the responsibility for your decision, don't blame others.

Some hardware is crap, yes, but it does not prevent the key from being configurable on dconf.

So... Gnome is forcing it's users to bow to windows because some computer manufacturers did?

Wonky hardware does make a compelling case for allowing the xrandr version to be the default option.

It does not make a case for removing the ability to configure alternate behavior.

A transparent solution is this: (although much more painful to implement than a simple configuration knob) Check the time difference between the presses of 'Super' and 'P' -- if it's greater than 10ms, it's a user's choice, otherwise do the screen transition.

I've been bitten by this bug and it really hurts my Gnome experience.

I don't get it why won't you include the patch that makes it configurable? I, for one, use Super+P for different task.

Again, there is no reason to reject this patch. I vote it bug reopened.

(In reply to comment #1)
> Not going to happen. Windows+P is what Windows uses to cycle through display.
> That's not why we support it however. The problem is that BIOS vendors, instead
> of making their "display" key report something useful, made it appear as though
> "Windows+P" was pressed (sometimes even followed by a Return, to make sure it
> was taken into account).
> 
> That's just crap, but there's a large amount of computers that expect Windows+P
> to do something within the OS, so we have to support it.

Nobody is asking you not to support this stupid BIOS behaviour. What I (and other people with unaffected BIOSes) would like is an option to stop g-s-d from overtaking the key binding permanently. If you feel that a large portion of the population is affected by such broken BIOSes then fine, leave it as a default, but give people an option to turn it off without having to completely stop using g-s-d.

I agree with Eduardo Habkost that the current situation is just sloppy. Let's not be lazy and let's fix this properly. If you don't have time to do this, then make that clear so that someone else would do it. I'm sure at least one of the affected people would be able and willing to help (hint: I could try it).

Please read the comments and reopen.

Please reopen and address the patch.

Comment 1 still stands.

Comment 1 doesn't explain why it needs to be hardcoded. We should be able to disable that behavior without recompiling gnome-settings-daemon.

This is beyond tiring.

Please fix this bug (and yes, as it currently stands, it *is* a bug) by making the behaviour configurable. I understand that you're trying to be userfriendly, but this is seriously throwing the baby out with the bathwater.

Comment 1 still stands, as it did 2 years ago.

Bastien,

Comment 1 doesn't address at all what I (and most others, among them David, Hendrik and Michael) was talking about.

I don't mind you keeping the behaviour as the default if you feel that this is the more generally useful choice, but allow those it hurts to at least turn it off.

Bastien, I could not have been more plain spoken in Comment 9. There is no reason for this to be hard coded. Our freedom to tinker is being infringed. Do we have to fork the entire project just to be able to override this policy on my own box? I thought free software is about empowering users...

(In reply to comment #13)
> Bastien, I could not have been more plain spoken in Comment 9. There is no
> reason for this to be hard coded.

We don't ship a bag of bits, and I'm not going to let users of Win7 or Win8 certified laptops shoot themselves in the foot.

> Our freedom to tinker is being infringed.

The code is still free, in fact, all the code I write is free.

> Do
> we have to fork the entire project just to be able to override this policy on
> my own box? I thought free software is about empowering users...

I'll go back to being productive so the users can be empowered by great software :)

Bastien,

you still misunderstand us.


I'm sure you have a lot to do, but I think it would be a great relief to us if you could bring this discussion to a resolution. Please read our argument carefully and answering to it (as opposed to, it seems to me, just skimming the bug report and replying to what you mistakenly think our request is).


I think I speak for everyone here if I say that I'm perfectly fine with the default behaviour accomodating certain laptops. To me, this appears to be the right choice.

What we're asking for is a solution to alter this behaviour (that appears to be baked into the code).

Currently, the only solutions we have are disabling entire modules of GNOME outright, or forking and recompiling GNOME. Both of these solutions  certainly seem out of proportion in order to get rid of a shortcut.

Please provide us with a way to control the behaviour of Super-p (and similar magic keys), e.g. through dconf.

I'd even do the work for you (so you can continue empowering users through great software) by providing a patch myself, but I'm certain you would shoot it down. This is unfortunate.

Thanks
Luca

On OSX Win/Super/Command + P is used to print the page, not the change resolution. Please see: http://support.apple.com/kb/ht1343

This causes horrible accidents when using normal PC keyboard on a MAC, and then switching between GNOME/Linux and OSX...

Please re-open and fix the bug. This is affecting usability.

Creating a bugzilla account in order to add another voice begging for this to be re-opened.

As discussed, the default behaviour should not change: s-p would continue to trigger the VIDEO_OUT_KEY behaviour by default; but users would have some way of disabling that behaviour -- independently of other behaviours -- if they need to.

Concern was raised over the possibility of users of Win7 or Win8 certified laptops "shoot[ing] themselves in the foot" if they were able to disable this. I presume the worry is that a user with one of these laptops might wish to use that key sequence for some other purpose (as do we all), disable it (using the hypothetical configuration option), but not realise that doing so would also affect the separate "display" key on their laptop, and subsequently run into problems when they press their "display" key (whereupon s-p would be sent by the BIOS, resulting not in the VIDEO_OUT_KEY action, but instead whatever it is that the user had reconfigured that key sequence to do (or possibly just sending a "p" if the key had no binding?))

That's an entirely reasonable concern, but it's not an insurmountable one; and this situation is so infuriating that it definitely warrants a proper solution.

Other people might like to make other suggestions (please do). The one which springs to my mind is for some kind of validation/confirmation dialogue to be triggered when a user re-configures this key, explaining in plain language the relationship between s-p and the "display" key on these kinds of laptops, thus ensuring that the use cannot make this change without being told what the consequence is. (When configuring dconf from the shell, a warning message could be sent to stdout?)

Some people will just click through, yes; but there must be dozens of ways to shoot yourself in the foot by making ill-considered changes in dconf-editor. I don't believe this particular case is different enough to warrant this sort of enforced behaviour.

For the (surely small) number of people who might still succeed in shooting themselves in the foot, I have faith that search engines would quickly point them at the right solution (just as they doubtless would with all the other problems they must be causing for themselves by not reading things).

I don't know whether dconf-editor currently has support for such dialogs or warnings. I know it has a description field, but I can more easily envisage people not paying attention to that. If there's no such facility then I do worry that I am proposing a lot of work to resolve this issue with s-p, but as the foot-shooting case is the major road-block here, I suspect it needs to be addressed somehow. Again, perhaps others can propose simpler solutions.

For cross-reference purposes, people reading this might well be interested in "A hack to rescue Super+P from gnome-settings-daemon": http://blog.n01se.net/blog-n01se-net-p-314.html

Bastien Nocera:
You think comment #1 still holds :"a large amount of computers that expect Windows+P...", but how much is the portion in total? Can you show a number?

Another argument for reopening and making the shortcut configurable is to make it possible to use the video out media key with dvorak or colemak keyboard layouts.
With these layouts pressing video out key results in <super>+l (dvorak) or <super>+; (colemak) and as a result the multimedia key does not work as expected.
It's possible that other keyboard layouts are also affected. 
By making it possible to configure the shortcut it could be adjusted to trigger correct action.

See also my comment here: https://bugzilla.gnome.org/show_bug.cgi?id=623223#c36

Without delving into the complexities of allowing the key to be rebound on broken machines without confusing users, 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.

See #736430.

*** Bug 736430 has been marked as a duplicate of this bug. ***

(In reply to Reuben Thomas from comment #20)

+1.

My system runs Fedora 21 with Gnome 3.14. My keyboard does not have any multimedia keys. I have created few shortcuts to start frequently used applications, to name a few: Super+W starts web browser, Super+E start my favorite text editor, Super+T starts Gnome terminal, etc. ...and Super+P to start Pidgin. All the shortcuts work well, BUT Super+P has no effect. When I press Super+P I do not see any reaction. Pidgin is not started. I double checked all the assignments. All shortcuts work but not Super+P.

Later I found the reason (and this bug report). Frankly, I do not fully understand reasoning. Ok, there are some ugly laptop BIOSes which generate Super+P instead of sending some new keycode… But why it affects me? My system is not a laptop, I do not have any hardware buttons, so why I can't use Super+P?

Anyway, even if you are not going to let me use Super+P, we still have a problem:

If I am not allowed to use Super+P, why gnome-control-center accepts it? When I assign Super+P to a command, gnome-control-center should warn me: "The shortcut "Super+P" is already used for blah-blah-blah, you can't reassign it".

For the love of god will you please just get off your high horse and allow this to be configurable.

I am absolutely fed up of accidentally hitting this stupid key and completely screwing up my multi-monitor configuration as a result often leaving me having to logout and in again to get back to sanity.

Please see https://wiki.gnome.org/Foundation/CodeOfConduct - if you are after insulting people, GNOME Bugzilla is not the right place. Not picking up specific technical arguments in previous comments does not help convince anybody either.

Sorry, I wasn't trying to insult anybody, but this has been going on for years, and there's a perfectly good patch and yet everybody is just ignored.

What is the technical argument? I can't actually see one or I would happily argue against it.

I can see the argument for making it default to what it does, but the only argument against allowing it be changed seems to be that somebody might accidentally break stop their video switch key working, which is a pretty slim argument if you ask me...

If the only argument for allowing it to be changed was so that people could use it as a custom hot key then that would be one things, but there are situations like mine where the current behaviour is actively damaging not just inconvenient.

I have three monitors arranged (per the Gnome numbering) as 2, 1, 3 from left to right. Monitors 2 and 3 are rotated through 90 degrees.

If I accidentally hit that button (because I'm trying to hit Alt-P which is next to it) then suddenly my monitors are reordered as 1, 2, 3 and the rotations are all reset.

Even if I manage to put things back with the display control panel all my window sizes are likely messed up as a result, and the total result is that at best I lose five minutes while I put everything back how it was meant to be and at worst I have to log out and in again.

To be honest I don't even mind if there's no way to disable it in the GUI at all - just a secret dconf key you have to set by hand would be fine!

André,

Tom was not being insulting. Remember,
"If something seems outrageous, check that you did not misinterpret it."

I fact I submit that Bastien does not
"Be patient and generous:
If someone asks for help it is because they need it. "

I think Tom (like many people) is just exasperated by Bastien's apparent unwillingness to listen to reason and purposely rejecting practical solutions, even those delivered as patches in open source spirit.

TBH, I've turned my back on Gnome partly because of how this issue was handled. I only remain on CC because I am curious to see whether the Gnome team will eventually realise that they are unreasonable.

(In reply to Reuben Thomas from comment #20)
> Without delving into the complexities of allowing the key to be rebound on
> broken machines without confusing users, 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.

That's a long-standing bug for the keyboard panel, see bug 670579

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

That would need:
- a udev rule, shipped by systemd, that would mark the /devices/virtual/dmi/id device as using that key, for affected machines. I'd start with all the Dell and HP machines:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/539477
- then, a work-around in gnome-settings-daemon to look for that tag, and only catch Win+P on those machines.

I'll even go as far as writing the gnome-settings-daemon patch, but somebody else will have to drive those systemd/udev changes.

I will still not make this configurable and strand users of Dell and HP laptops, sorry.

See also:
http://www.advogato.org/person/mjg59/diary.html?start=243

Thanks very much for the pointer, references and offer of help, Bastien.

The reference to Dell and HP also helps to expose the scope of the problem, i.e. likely to be getting worse rather than better.

I don't understand why you characterise a hidden setting as "stranding" users, since the only way one can find such a setting in the first place is by having some understanding of the problem. As it is, users of such machines have no alternative to recompiling parts of GNOME if they want to use Super+P for something else. A hidden setting whose description has a warning and a link to a suitable explanation of the problem (e.g. this bug) is surely enough? Anyone using dconf directly in the first place already (ought to) know(s) that "here be dragons"!

(In reply to Reuben Thomas from comment #30)
> Thanks very much for the pointer, references and offer of help, Bastien.
> 
> The reference to Dell and HP also helps to expose the scope of the problem,
> i.e. likely to be getting worse rather than better.
> 
> I don't understand why you characterise a hidden setting as "stranding"
> users, since the only way one can find such a setting in the first place is
> by having some understanding of the problem. As it is, users of such
> machines have no alternative to recompiling parts of GNOME if they want to
> use Super+P for something else. A hidden setting whose description has a
> warning and a link to a suitable explanation of the problem (e.g. this bug)
> is surely enough? Anyone using dconf directly in the first place already
> (ought to) know(s) that "here be dragons"!

Except that it's not how the availability of those settings ends up being seen. We regularly have to fix hidden settings that are there to support marginal use cases, such as when we end up breaking those either by mistake or on purpose.

And at the end of the day, I'm not interested in adding a configuration option when this bug can be fixed without adding more moving parts.

Sorry, I must have overlooked how you fix the ability to rebind Super+P for Dell & HP users, but I'm glad it is possible, and I agree it's much better to fix it without "adding more moving parts".

I will try to get around to working on this soon. I have just wasted several minutes reconfiguring my two displays, as I do every other month or so, when I press Super+P by mistake and end up with the displays mirrored.

*** Bug 789334 has been marked as a duplicate of this bug. ***

*** Bug 789334 has been marked as a duplicate of this bug. ***

*** This bug has been marked as a duplicate of bug 792892 ***