Comment 26 for bug 704231
Revision history for this message
| Sam Spilsbury (smspillaz) wrote Re: [Compiz] [Bug 704231] Re: Unity steals <super> modifier key | #26 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
7020100
(Get the code!)
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://
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:/
>
> Title:
> Unity steals <super> modifier key
>
> To manage notifications about this bug go to:
> https:/
>
> _______
> Mailing list: https:/
> Post to : <email address hidden>
> Unsubscribe : https:/
> More help : https:/
>