From 67dd0b4fec6eecb6fa6c7ed6784820901a53e2bf Mon Sep 17 00:00:00 2001 From: Carlos Garnacho Date: Thu, 12 Mar 2020 19:26:37 +0100 Subject: [PATCH 23/48] keybindings: Avoid double calls to process_event() on the same event If you first press a key that triggers the "special modifier key" paths (ctrl, super), and then press another key that doesn't match (yet?) any keybindings (eg. ctrl+alt, super+x), the second key press goes twice through process_event(), once in the processing of this so far special combination and another while we let the event through. In order to keep things consistent, handle it differently depending on whether we are a wayland compositor or not. For X11, consider the event handled after the call to process_event() in process_special_modifier_key(). For Wayland, as XIAllowEvents is not the mechanism that allows clients see the key event, we can just fall through the regular paths, without this special handling. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1014 --- src/core/keybindings.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/src/core/keybindings.c b/src/core/keybindings.c index ab1ace5ae..2cf705598 100644 --- a/src/core/keybindings.c +++ b/src/core/keybindings.c @@ -2037,6 +2037,13 @@ process_special_modifier_key (MetaDisplay *display, { *modifier_press_only = FALSE; + /* If this is a wayland session, we can avoid the shenanigans + * about passive grabs below, and let the event continue to + * be processed through the regular paths. + */ + if (!xdisplay) + return FALSE; + /* OK, the user hit modifier+key rather than pressing and * releasing the modifier key alone. We want to handle the key * sequence "normally". Unfortunately, using @@ -2069,8 +2076,6 @@ process_special_modifier_key (MetaDisplay *display, XIAllowEvents (xdisplay, clutter_input_device_get_device_id (event->device), XIReplayDevice, event->time); - - return FALSE; } } else if (event->type == CLUTTER_KEY_RELEASE) -- 2.26.0.rc2