GNOME Bugzilla – Bug 699787
win32: discard fake Control keyboard events
Last modified: 2018-05-02 15:37:04 UTC
With some layouts (apprently many of the non-english ones), the client receives two consecutive keyboard input events when pressing AltGr. See also Spice client bug https://bugzilla.redhat.com/show_bug.cgi?id=956686
Created attachment 243440 [details] [review] win32: discard fake Control keyboard events This seems to be a pretty undocumented aspect of Windows keyboard input, with some layouts (apprently many of the non-english ones), the client receives two consecutive keyboard input events when pressing AltGr. There doesn't seem to be any way to nicely avoid or discard those extra events since they really are just like the "real" ones. There has been some workaround in Xwin: http://cgit.freedesktop.org/xorg/xserver/tree/hw/xwin/winkeybd.c I adapted this code to experiment with it. It seems that the checking of the previous event isn't necessary and actually discard valid simultaneous key presses such as left alt+ctrl. However, I always get the next event in the message queue when pressing AltGr, so the basic idea seems to solve the issue.
ping
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
This was fixed in our gtk2 build. The bug didn't reopen itself after moving to gtk3. Yet I bet this is still relevant (given that other code have similar workarounds), let's make it low priority.
I'm not authorized to see the original bug report at redhat bugzilla. Could you provide (copypasting is OK, i guess) more detailed instructions on how to reproduce this (preferably with just a simple GTK app, or GTK-demo/widgetfactory, and without any layouts that can't be installed on Windows 10 normally)? I did some changes to W32 backend keyboard handling a while back, so i might be able to do something about it (or maybe just accept your patch).
Is winIsFakeCtrl_L comment in http://cgit.freedesktop.org/xorg/xserver/tree/hw/xwin/winkeybd.c enough to reproduce? (I don't have a windows handy)
Running gtk3-demo with GDK_DEBUG=events, i was able to reproduce this easily. Just press right Alt while using different keyboard layouts. For En-US layout: WM_SYSKEYDOWN 00931B3E 0x12 0x21380001 Right Alt ch:12 KF_ALTDOWN KF_EXTENDED sc:56 rep:1 ===> GDK_KEY_PRESS 00931B3E @ 673343937ms 0xa5 group:0 Alt_R 0:"" => 0 WM_SYSKEYUP 00931B3E 0x12 0xc1380001 Right Alt ch:12 KF_UP KF_REPEAT KF_EXTENDED sc:56 rep:1 ===> GDK_KEY_RELEASE 00931B3E @ 673344000ms 0xa5 group:0 Alt_R 0:"" => 0 For Ru-RU layout: WM_KEYDOWN 00931B3E 0x11 0x1d0001 Ctrl ch:11 sc:29 rep:1 ===> GDK_KEY_PRESS 00931B3E @ 673406328ms 0x11 group:1 Control_L 0:"" CONTROL => 0 WM_KEYDOWN 00931B3E 0x12 0x21380001 Right Alt ch:12 KF_ALTDOWN KF_EXTENDED sc:56 rep:1 ===> GDK_KEY_PRESS 00931B3E @ 673406343ms 0xa5 group:1 Alt_R 0:"" MOD2 => 0 WM_SYSKEYUP 00931B3E 0x11 0xe01d0001 Ctrl ch:11 KF_UP KF_REPEAT KF_ALTDOWN sc:29 rep:1 ===> GDK_KEY_RELEASE 00931B3E @ 673406390ms 0x11 group:1 Control_L 0:"" MOD1 => 0 WM_KEYUP 00931B3E 0x12 0xc1380001 Right Alt ch:12 KF_UP KF_REPEAT KF_EXTENDED sc:56 rep:1 ===> GDK_KEY_RELEASE 00931B3E @ 673406390ms 0xa5 group:1 Alt_R 0:"" => 0 I'll research it a bit more, then look at the patch.
I am reluctant to accept this patch. On one hand, GDK already combs through the keyboard layout, figuring out all the AltGr-enabled key combinations, and is therefore able to just produce any of them at will, given a virtual key code and a state of the keyboard modifiers (specifically - the MOD2 modifier that means AltGr in GDK W32 backend). Therefore, GDK does not need to let GTK see the extra CONTROL and MOD1 (Alt) modifiers that Windows sends our way. I think that in this case we'll also need to specifically enable MOD2 when Right Alt is pressed (currently GDK does not do that, but it does enable MOD2 on Ctrl+Alt that RightAlt triggers, but if that is going to be gone, we need to trigger MOD2 ourselves; shouldn't be a problem). On the other hand, this is an intentional Windows feature (instead of "Right Alt means AltGr" they made it so "Right Alt means Control+Alt, which means AltGr", or something like that). This is expected behaviour of the right Alt key on Windows. There conceivably could be applications that depend on this behvaiour being present. Is is OK to, for example, encourage RightAlt+something shortcuts, when that combination could be normally used to type a character on user's keyboard? I think that it should be possible to "fix" this in each specific application by implementing an event filter (gdk_window_add_filter()) that does exactly what your patch did - catch all WM_(SYS)KEY(UP|DOWN) and ignore extra Ctrl that precede a Right Alt with the same timestamp. Ideally, you'd also check the keymap for having AltGr enabled, but _gdk_win32_keymap_has_altgr() shouldn't be used by applications. Maybe we could start with that.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/420.