GNOME Bugzilla – Bug 782534
GdkKeymap modifier state doesn't seem work under wayland
Last modified: 2017-09-05 14:31:38 UTC
Created attachment 351669 [details] test case When running Gtk+ applications under wayland, it seems that the gdk_keymap_get_modifier_state() always returns 0 for the default keymap, and the 'state-changed' signal does not get emitted when (for example) the caps lock is depressed. When running under x11, the signal *does* get emitted. Minimal test case attached. Compile and run the test case executable and press various modifiers (caps lock, shift, ctrl, num lock, etc). When the test case is run under Wayland, I get an initial signal immediately after the executable starts and the debug output indicates that the modifier state is 0 regardless of whether any modifiers are active. When the test case is run under X11, a new message is printed to the terminal every time a modifier is activated or de-activated.
After a little more investigation, I've noticed that if I modify my test case slightly by instantiating a GtkWindow, the state-changed signal does get emitted, but only if the window is focused. Is that expected?
short answer: yes
Is there a longer answer? Should I just close this bug?
The longer answer is that even though the wayland protocol is not explicit about modifiers being broadcasted or not to all clients, both mutter and weston treat wl_keyboard.modifiers as tied to the keyboard and pointer focus surface, so it implies there is one. Given the protocol is lax here, and both weston/mutter follow the same page, I think the wayland-devel ML is a better forum if you disagree about this behavior.
I can answer easily, since I wrote it: the intention of the spec is what Weston and Mutter both do, i.e. only notifying active/focused clients rather than broadcasting. The intention was to allow people to interpret key and button/axis information correctly. If you're trying to do something like show caps lock status in a window, then the way to do that would be from within the compositor.
Fair enough. I don't think this is actually a problem for us. I just happened to notice that the behavior was inconsistent it while I was debugging a somewhat related issue. I think it would be good to document the difference in behavior somewhere, though.
So, it seems this isn't a bug on the GTK+ side (or at all). If it turns out that you want any added documentation on the GTK+ side, please do open a new bug indicating where clarification would be useful.