After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 737134 - Keyboard shortcuts broken with non-default keyboard layout (German Neo 2.0)
Keyboard shortcuts broken with non-default keyboard layout (German Neo 2.0)
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: general
3.13.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2014-09-22 17:41 UTC by knittl89+gnome
Modified: 2014-09-24 21:25 UTC
See Also:
GNOME target: ---
GNOME version: 3.13/3.14


Attachments
keybindings: Do a breadth first search in our keysym to keycode code (3.49 KB, patch)
2014-09-23 16:05 UTC, Rui Matos
accepted-commit_now Details | Review
keybindings: Do a breadth first search in our keysym to keycode code (5.33 KB, patch)
2014-09-23 17:56 UTC, Rui Matos
committed Details | Review

Description knittl89+gnome 2014-09-22 17:41:33 UTC
Keyboard shortcuts are broken with Gnome 3.13 when using the German Neo 2.0 layout.

For shortcuts such as super-b (open browser), super-a (show applications), super-s (show overview), I need to press the key as if my layout was actually a qwerty/qwertz layout.

Other shortcuts, most notably those involving cursor keys or special keys, don't work, for instance alt-tab to switch applications, ctrl-alt-down to switch workspaces.

I noticed however, that pressing ctrl-alt-a switches the workspace (the "a" key on Neo contains the down cursor key on a higher Xorg level). Same goes for ctrl-alt-l ("l" has the up cursor key on a higher level).

After setting the layout with "setxkbmap de neo -option", shortcuts with the super key plus letters work as expected (e.g. super-t opens a terminal). However, if the letter key contains a cursor key on a higher level, the higher level shortcut is used, for instance super-e will maximize a window to the right side of the screen (again, "e" contains the left cursor key)

Any help appreciated. If more information is required, feel free to ask for it, and I will try my best to provide it.
Comment 1 Rui Matos 2014-09-23 16:05:17 UTC
Created attachment 286893 [details] [review]
keybindings: Do a breadth first search in our keysym to keycode code

Commit 1af00333682cda21db2d08b9fc590888d8e23e57 made a subtle change
regarding how XKeysymToKeycode behaves. It does a depth first search
while XKeysymToKeycode is documented to do a breadth first search:

"this function looks in each column of the core keyboard mapping in
turn and returns the lowest numbered key that matches in the lowest
numbered group" - from the XKB library documentation

Doing a complete search for each layout index makes us go back to the
previous behavior.
Comment 2 Jasper St. Pierre (not reading bugmail) 2014-09-23 16:11:40 UTC
Review of attachment 286893 [details] [review]:

Minor nit, otherwise looks fine.

Sorry about this one.

::: src/core/keybindings.c
@@ +314,3 @@
+    for (i = 0; i < xkb_keymap_num_layouts (keymap); i++)
+      {
+        search_data.layout = i;

FindKeysymData search_data = { retval, keysym, i };
Comment 3 Rui Matos 2014-09-23 17:56:10 UTC
Created attachment 286907 [details] [review]
keybindings: Do a breadth first search in our keysym to keycode code

Commit 1af00333682cda21db2d08b9fc590888d8e23e57 made a subtle change
regarding how XKeysymToKeycode behaves. It does a depth first search
while XKeysymToKeycode is documented to do a breadth first search:

"this function looks in each column of the core keyboard mapping in
turn and returns the lowest numbered key that matches in the lowest
numbered group" - from the XKB library documentation

Looping over all keycodes for each layout and level index makes us go
back to the previous behavior.

--

The previous patch didn't fix the original issue reported here because
it was still going through each level depth first. This one is now
doing breadth first on both layouts and levels and does fix the issue
here.

It seems to me that it might make sense to move some of this into
libxkbcommon, at least the API to get the max number of levels in a
keymap. Jasper?
Comment 4 Jasper St. Pierre (not reading bugmail) 2014-09-23 19:01:04 UTC
Review of attachment 286907 [details] [review]:

::: src/core/keybindings.c
@@ +281,1 @@
     g_array_append_val (keycodes, keycode);

At this point, it's probably simpler to inline is_keycode_for_keysym here.

@@ +365,3 @@
+
+  keys->keymap_num_levels = 0;
+  xkb_keymap_key_for_each (keymap, determine_keymap_num_levels_iter, &keys->keymap_num_levels);

Gross. Let's plan on replacing this when libxkbcommon grows a proper API. I'm fine with accepting this for now.
Comment 5 knittl89+gnome 2014-09-23 19:26:49 UTC
One thing I missed explaining in my initial bug report: I do not have multiple layout configured. I only have one single layout "German (Neo 2)" configured for my user as well as for the login screen.
Still, gnome is receiving some shortcuts as if pressed on a qwert* layout (super-t does nothing, super-w opens a terminal. With Neo, "w" is on the physical "t" key)

Not sure whether this is important for the fix or not, but I thought it should be mentioned anyway.
Comment 6 Marc-Antoine Perennou 2014-09-24 14:57:28 UTC
I have the same problem here, and this patch fixes it too.
Could we get this in?
Comment 7 Rui Matos 2014-09-24 21:25:29 UTC
We can simplify this if/when
https://github.com/xkbcommon/libxkbcommon/pull/12 lands in
libxkbcommon.

Attachment 286907 [details] pushed as 60c22b6 - keybindings: Do a breadth first search in our keysym to keycode code