GNOME Bugzilla – Bug 778019
Key repeat under wayland behaves differently, making keyboard navigation e.g. in vim annoyingly unreliable
Last modified: 2017-08-08 00:45:08 UTC
The key repeat under wayland appears to behave differently, making keyboard navigation e.g. in vim annoyingly unreliable. To reproduce, try the following steps: 1. Open a file in vim (or a similar console editor) in gnome-terminal 2. The file should have at least 10 lines, which are all between 60 and 70 characters in length, filling up roughly the terminal width 3. Press down to start navigating downwards 4. Press right and as quickly as you can AFTERWARDS, release down Result on X11: cursor navigates to the right until end of line or until right key is released Result on Wayland: cursor stops with releasing the down key, despite right key still being pressed. Since those "overlaps" between pressing cursor keys are something that simply happens accidentally when navigating around, this makes keyboard navigation feel unreliable and buggy.
Key repeat in Wayland in managed by the client - in the case of GTK+, this is done in gdk/wayland/gdkdevice-wayland.c The key repeat is stopped as soon a a key is pressed, so if we go like: key1 press key1 repeat key2 press -> key1 repeat stopped key1 release -> means the key repeat is stopped even though key2 is still pressed.
Created attachment 344764 [details] [review] [PATCH] wayland: do not cancel key repeat on key press The key repeat is stopped as soon as a key is pressed, so if the user quickly presses a key while another is already pressed and being repeated, key repeat gets cancelled: - key1 press - key1 repeat - key2 press -> key1 repeat stopped - key1 release - key 2 is not repeated even though it's kept depressed This is a different behavior from X11, which confuses migrating users. To mimic the X11 behavior, keep track of the number of keys pressed simultaneously and cancel key repeat only when none is pressed. This way, if a user pressed a key while another one is being repeated, the new key press can possibly be repeated as well.
Review of attachment 344764 [details] [review]: Looks good! just a minor comment, feel free to push after fixing. ::: gdk/wayland/gdkdevice-wayland.c @@ +2154,1 @@ seat->repeat_count++; This should probably only happen if state!=0, not that it matters much in practice, since we just ever check for repeat_count == 1.
(In reply to Carlos Garnacho from comment #3) > Review of attachment 344764 [details] [review] [review]: > > Looks good! just a minor comment, feel free to push after fixing. > > ::: gdk/wayland/gdkdevice-wayland.c > @@ +2154,1 @@ > seat->repeat_count++; > > This should probably only happen if state!=0, not that it matters much in > practice, since we just ever check for repeat_count == 1. Err nope, if we do repeat_count++ only on key press (i.e. state != 0) we don't get the expected behavior, the repeat pauses twice.
Corollary question, do we want this patch in master and gtk-3-22 or just in master? (i.e. is it matter for the stable branch or not?)
Since this has basically no after effects, let's not bother with it, the patch looks good :). IMO makes sense for gtk-3-22, key repeat behavior is not part of ABI, and if it were we already broke it in wayland.
Comment on attachment 344764 [details] [review] [PATCH] wayland: do not cancel key repeat on key press attachment 344764 [details] [review] pushed to git master as commit 4c533e1 - wayland: do not cancel key repeat on key press attachment 344764 [details] [review] pushed to branch gtk-3-22 as commit 4146d7f - wayland: do not cancel key repeat on key press
While the use case described above now works (I have GTK+ 3.22.17), there is another behavior difference to X11 that still remains: 1. Press and hold a letter 2. Now press and hold shift while the letter is still pressed On X11, you'll now get uppercase repeat of the letter. In the wayland session, the repeat stops as soon as shift is pressed. I'm not sure this is needed by anyone, I just wanted to point it out in case it is unintentional and someone considers it worth keeping for some reason.