Unity blocks other programs from receiving <super> key-press events.

Yes, this should be documented. Super will be the primary key for window
management and other Unity functions.

This is a compiz bug which grabs the key even when the functions are returning False:
In the unity code:

bool
UnityScreen::showLauncherKeyInitiate (CompAction *action,
                                      CompAction::State state,
                                      CompOption::Vector &options)
{
  // to receive the Terminate event
  if (state & CompAction::StateInitKey)
    action->setState (action->state () | CompAction::StateTermKey);

  launcher->ForceShowLauncherStart ();
  return false;
}

bool
UnityScreen::showLauncherKeyTerminate (CompAction *action,
                                       CompAction::State state,
                                       CompOption::Vector &options)
{
  launcher->ForceShowLauncherEnd ();
  return false;
}

--------------------
Sam told:
11:04:03 smspillaz | didrocks: I mean, I guess I could make a returning false action do XPutBackEvent

It is a real usability issue especially as I depend on zoom-in/out with <super>+<button4>/<button5> (aka mouse wheel) as a visually impaired.
I really wonder why Unity preval use of <super>. Even not using unity here with classic ubuntu desktop and I can't zoom in out after selecting a window?

@Léa: this is not related to that bug. We disabled zoom-in/out by default in the configuration, you can set it back in ccsm.
see bug #684925 for the rationale.

There is a pending request about setting it back only when you activate accessibility, which would make sense.

Actually I have already re/enabled mouse wheel events for zoom control in compiz using CCSM but, the events are not recieved by compiz when I select/click a window area. I have to be hover some window decoration area for compiz to recieve the wheel super+wheel events, or must step some window switcher before. In all other cases, it no longer work despite beying enabled in compiz.

~/.config/compiz-1/compizconfig/Default.ini
Already having :
[ezoom]
s0_zoom_in_button = <Super>Button4
s0_zoom_out_button = <Super>Button5

Likewise - I never realized how much I use this, until I switched to unity and was unable to zoom or launch gnome-do.

Can I add that if you press super+D quickly the unity dash will appear AND the windows will minimize/maximize. Should be fixed. Dunno if this is the right place for if I should file a new bug?

I thought unity was modified here to drop the super key from the compiz event dispatchers?

Added a test case

lp:~smspillaz/+junk/grabtests

HOW TO TEST:

1) Unload the unity plugin (seems to be a bug in cairo that causes a crash with no backtrace here, not sure what's up with that). Unloading the unity plugin DOES NOT affect the results of this test, since it is a test of compiz core NOT unity.
2) Load the "Test Grabs" plugin
3) Launch compiz in a terminal (eg compiz --replace ccp &)
4) Press Control-Alt-t, which should display a message
5) Press Control-Alt-y, which should display a message, releasing Control or Alt will display another, releasing y will NOT
6) Press Control-Alt-i, which should display a message, pressing any other key should also display a message, until Control-Alt-i pressed again
7) Press Control-Alt-o, which should display a message, pressing keys Q W E R T Y should also display a message, any other key should "pass through" to applications, until Control-Alt-o pressed again
8) Launch app/testgrabs, enter "1" if the window displayed, press a, press control-a and it will exit. A message will be displayed in testgrabs and in compiz, saying that you pressed Control, but the app will still get Control-a this time around.

the branch wasn't merged

The fix for this is too risky, not targeting for this milestone

This also prevents VirtualBox from using superkey in window mode. To use the super key in VirtualBox, the guest has to be in fullscreen. IMHO I think this is a bad idea. I use the superkey for the virtualized guest as often as I do for the host.

I don't know if this is because of Unity, but this behavior did appear in 11.04 with Unity.

I'm pretty confused why this isn't a config issue, or a very simple fix - aren't we talking a boolean here?

I understand Mark's desire to have a simple and consistent behaviour at the desktop level, but the gross implementation chosen not only grabs the use of Super as a solo key, (as intended), but also apparently in any combination with other keys.

Until this behaviour came along I understand tens or hundreds of projects were employing Super+ key combinations quite happily. I for one was using both Gnome-Do's default key mappings and Scale (with Super+Shift+W for 'window group' as well as Super+W for 'all windows') every day. Since this is a desktop-level intervention, there's little that any of them can do to fix this without Ubuntu's cooperation. It also silently breaks CCSM since any keys chosen there which include Super+ are plain ignored.

Why the unwillingness to work with the CCSM engine to allocate and manage conflicts between keymappings here? It's not as if Ubuntu provides an alternative. As far as I can see, the Keyboard Shortcuts app distributed with Ubuntu provides no meaningful configuration of the Unity Super+ options, so working constructively with CCSM could provide a usable configuration interface for those shortcuts too.

Since super keys were properly dispatched before, and multiple Compiz plugins have managed to co-exist for years using different combinations of the super key, why is it that Unity still breaks every possible Super+ combination?

Loath to switch back to Classic and be a dinosaur on this, but losing my most central desktop control behaviours is a lot of grief.

Agree 1000x with Cefn.

The Keyboard Shortcuts applet is now broken. It allows you to assign super key behaviors which simply don't work, they all fail silently. This is a major bug and a regression. A very frustrating one I might add.

Note that this also means that when running with an Apple keyboard, you cannot swap the Option and Command keys to get PC-like behaviour.

I was wrong. Please disregard comment 16

The keystroke theft occurs even when VirtualBox is in full-screen mode. This is probably only visible when you have a multihead setup with fullscreen VirtualBox in some monitors, but not all.

Agree with Cefn and Exquisite Dead Guy.

1. This behaviour breaks the functionality of Keyboard Shortcuts applet, (which is included with Ubuntu) and does so without giving any reason or warning. This makes for an inconsistent experience in Ubuntu.
Perhaps a seperate bug report should be made regarding this alone?

2. This even breaks functionality that would be considered part of core desktop functionality such as Super + L to Lock Screen.

Very annoying.

After upgrading today, I was pleased to experience my Super + Space binding (for GNOME Do) working as expected in Oneiric! :)

Not sure of the revision but there is a fix for this now in compiz core. Going to mark as fix released.

It still happens in Ubuntu 11.10 with VirtualBox and apparently VMware Workstation as well. Super is stolen from 'em.

See also https://bugs.launchpad.net/unity/+bug/806255 and http://askubuntu.com/questions/70177/unity-vmware-workstation-and-the-super-windows-key

Also in a fullscreen NX session. Pressing super pops up the Unity dash of the client PC over the NX root window. You can not close it with the buttons, as the click goes to NX, not Unity. Should I report this as a new bug?

Can someone please point me to the exact code that was meant to fix this bug?

If the fix did indeed make it into oneiric, then it still needs to be improved because it's still happening. Bug 806255 is evidence of this.

A proper fix should be simple in theory: If any X keyboard grabs exist then Unity shouldn't be responding to any keys.

On Sat, 19 Nov 2011, Daniel van Vugt wrote:

> Can someone please point me to the exact code that was meant to fix this
> bug?
>
> If the fix did indeed make it into oneiric, then it still needs to be
> improved because it's still happening. Bug 806255 is evidence of this.
>

Hi,

I believe
http://bazaar.launchpad.net/~compiz-team/compiz-core/oneiric/view/head:/src/event.cpp#L1023

is probably what you're looking for. That code ungrabs the keyboard if a
plugin doesn't explcitly grab the keyboard (eg, using screen->pushGrab ())
while a key event is being handled and the action is dispatched. This
means that if you held down the super key, the grab would persist from the
time of the super key being pressed, to when the plugin handles the
action.

Unfortunately that's not a perfect solution to this problem, and I haven't
been able to find one. X Grabs are inherently racy, and when we have a
keybinding set *only* on the super key, doing a passive grab on the super
key also implicitly does a passive grab on every other modifier
combination that uses the super key, and that grab remains until it is
released. This means that if you were to hit super-space to trigger
gnome-do really really quickly before compiz had a chance to dispatch the
action and release the grab then that the other application wouldn't get
the KeyPress event.

The grab is required in order to get the notification that the KeyPress
happened on the super key (cannot register for KeyPress events on windows
we don't own).

In terms of your other solution by not doing anything if another
application has a grab, I don't think that will solve this problem. First
of all, the key-action requires the passive grab to work (which is what's
causing the problem here) and second of all, even if that were the case,
there's still a race window where the application registers for the grab
and its output buffer hasn't been flushed yet, so you'd get the dash +
(whatever). Or worse, there would be unpredictable behaviour depending on
which application gets there first.

I think that the best solution to this problem is to have a flag in the
metadata which says "I won't require an active grab", so then you have a
reduced amount of time for which the race can happen (since we can release
the grab the moment the action gets dispatched). It might also be safe to
release the grab in any event, but then there's the consequence of
grabbing twice and dealing with things like, eg, focus changes that happen
as a result.

> --
> You received this bug notification because you are a member of compiz
> packagers, which is subscribed to compiz in Ubuntu.
> https://bugs.launchpad.net/bugs/704231
>
> Title:
> Unity steals <super> modifier key
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/unity/+bug/704231/+subscriptions
>
> _______________________________________________
> Mailing list: https://launchpad.net/~compiz
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~compiz
> More help : https://help.launchpad.net/ListHelp
>

It looks to me like Robert Carr did the fix in upstream compiz:
http://git.compiz.org/compiz/core/commit/?id=6b8ecb998ce409462cfd72343696f4925aa33fdb

However the fix never made it into oneiric, oneiric-updates or precise yet:
http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/oneiric/compiz/oneiric/view/head:/src/event.cpp#L1025
http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/oneiric/compiz/oneiric-updates/view/head:/src/event.cpp#L1025
http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/compiz/precise/view/head:/src/event.cpp#L1025

I haven't tested Robert's fix myself. But assuming that's the one he was referring to in comment #21, it is not yet Fix Released in compiz (Ubuntu)... The Status is wrong.

On Sun, 20 Nov 2011, Daniel van Vugt wrote:

> It looks to me like Robert Carr did the fix in upstream compiz:
> http://git.compiz.org/compiz/core/commit/?id=6b8ecb998ce409462cfd72343696f4925aa33fdb
>
> However the fix never made it into oneiric, oneiric-updates or precise yet:
> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/oneiric/compiz/oneiric/view/head:/src/event.cpp#L1025
> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/oneiric/compiz/oneiric-updates/view/head:/src/event.cpp#L1025
> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/compiz/precise/view/head:/src/event.cpp#L1025
>
> I haven't tested Robert's fix myself. But assuming that's the one he was
> referring to in comment #21, it is not yet Fix Released in compiz
> (Ubuntu)... The Status is wrong.
>

Yes, that's correct. I'll backport that patch next week.

> --
> You received this bug notification because you are a member of compiz
> packagers, which is subscribed to compiz in Ubuntu.
> https://bugs.launchpad.net/bugs/704231
>
> Title:
> Unity steals <super> modifier key
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/unity/+bug/704231/+subscriptions
>
> _______________________________________________
> Mailing list: https://launchpad.net/~compiz
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~compiz
> More help : https://help.launchpad.net/ListHelp
>

Awesome, thanks. Is it possible to correct the bug status too?

I don't have permission to, I'll need to get didrocks to handle that

Very confusing.

This bug WAS fixed, and is fixed in oneiric right now. This bug was not fixed by the change that Robert Carr proposed however. That changed is not in oneiric, and seems to make no difference when I tested it today.

Whatever commit actually did fix this bug is a complete mystery. But gnome-do's <super><space> handling does now work in oneiric.

As for Unity stealing single Super keypresses from KVM/Vmware/etc that is still NOT fixed. Even Robert's patch made no difference. Please refer to bug 806255 for further discussion on that one.

This bug is not fixed in Oneiric, it exists currently and won't let other compiz plugins like scale work anymore. It was working on my initial install of Oneiric but has since resurfaced.

@traxxas, the bug description says that compiz bindings were working for the person who reported this bug. Only external programs (i.e. not compiz) had a problem with receiving <super> keypresses. I suggest you log a new bug, or find a different one that fits your symptoms better.

Personally, I just didn't like Unity using Super as a standalone button. (In the words of Alton Brown, "It's a uni-tasker!") I made Alt-F1 open the launcher, and disabled keyboard focus to the dash. While I was at it, I also made the dash appear only if I touched the upper-left corner. I still have to move my cursor below the panel to make this work, and Unity shortcuts stop working almost entirely, but it opened up the ability to set custom shortcuts again. For instance, Super-T (for Text) opens LibreOffice Writer instead of the trash bin, which I rarely use.

That said, I am not entirely against the dash or Unity interface. I still have all of that enabled, and use it frequently. I love being able to quickly find an application I need NOW by simply typing its name or command. I love that, despite the search being the default, which makes sense, I can still browse all my software to see if there's anything I haven't used in a while. It is also quite beautiful, and has great potential.

However, I miss being able to add and edit commands in the launcher. For instance, I would like to easily find the terminal command for (Program name here), or place Linux Multimedia Studio in the Unity launcher where it belongs, or maybe add my custom shell scripts to the launcher, set to run in the terminal or background according to a setting. All of that could be done with a right click. I like to customize it to best fit my needs, which is something that needs to be easier to do. MyUnity and CCSM help, but there is surely more that can be edited.

Just wondering is anyone still working on this issue?

I think this bug is fixed; at least the bug described in the Bug Description seems fixed anyway.

The issue with VMs is unresolved and should be discussed in bug 806255.

Closed. thanks Daniel.

This is marked as fixed, but on upgrading from 11.10 to 12.04, I seem to have lost Super key functionality again (for gnome-do and my IDE). Is there some configuration item that I'm missing to make it play nice?

The same thing for me. Super+L combination does not lock the screen after upgrade to 12.04. Any combination without Super (e.g. Ctrl-Alt-L) works fine.

I still can't reproduce this bug in 12.04. xev reports Super+Space correctly. However gnome-do fails to bind to Super+Space:

(Do:12793): libdo-WARNING **: Binding '<Super>space' failed!
[Error 11:33:27.893] [AbstractKeyBindingService] Failed to bind "Summon Do" to "<Super>space"

That's a separate issue which should be logged as a new bug if it's a problem for you.

I can still reproduce the issue:

Setup synergy with the Ubuntu 12.04 machine as master, Windows 7 machine as slave.
"<super>" set as "Key to show the launcher" in CompizConfig Settings Manager. (default)

Go onto the Windows desktop.
Press the Windows key (super).
Windows start menu displayed.
Return to the Linux desktop.
launcher menu displayed. (as if Super pressed on Linux desktop).

Also the same for the HUD:

Key to show the HUD == "<alt>" (default).

Do alt-tab on Windows desktop via synergy.
On return to Linux screen HUD is displayed.

Conclusion: Super and Alt are being duplicated by Compiz/Unity.

@Daniel: I agree. Over the past few days, I've noticed that gnome-do can successfully use super+space as a key binding, but that whenever I restart it, it loses the binding and I have to reassign it. Sorry for the noise.

What I am observing still is thus:

Background: Windows is running in VirtualBox, running in a Unity session. The VirtualBox keyboard lock is active.

If I tap the Super key, the Windows start menu and the Dash Home open. (Bad: Dash Home shouldn't open.)

If I hold the Super key for half a second and release it, the Windows start menu opens but the Dash Home does not. (Good.)

Ditto with the Alt key; on tap, the HUD opens when it shouldn't. However, if I tap Alt+Tab, the HUD also opens (which is inconsistent, suggesting that the Alt key gets through to Unity but the Tab key doesn't).

@Ryan, @Daniel: the issue you are having sounds to me like it's may be related to https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/991873

Chris, you are describing bug 806255. Please comment in that one.

Douglas, it sounds like you might also have bug 806255 rather than this one.

Daniel: is it possible that you've got a grab on <super> or somesuch? GNOME Do *can* receive <super>+<space> events (as your xev test shows), but attempting to add a grab on that combination fails (that's what the libdo-WARNING is about), which would be the case if Unity were grabbing the keys already.

raof, yes Unity does cause Compiz to add passive grabs on Super+AnyKey (on the root window I think). Whenever a plugin requests to bind to a single modifier key, Compiz has to also bind to modifier+everything_else so as to be able to distinguish between the modifier being tapped (for the plugin) or being used as a modifier for some other key. This only happens with the unityshell plugin which likes to use Super and Alt for the Dash and HUD.

So yes, it sounds like Unity is probably blocking other apps from binding to Super+anything on the root window. And I'm not sure if there is a safe way to avoid it without unbinding Unity from the Super key completely.

P.S. XKB is not a solution. It causes more problems than it solves because it does not honour active grabs. Hence bug 806255.

Right, as I suspected.

I'm in the process of working around this in Do by actually reporting an error when binding the keys fail, so at least users have some idea of why things aren't working.

We might want some documentation that clearly states that all <super>s are belong to Unity.

Discussion continues in bug 950160.