I'm seeing the same issue (also using German Neo2 keyboard layout). This not only affects the <Super>+L keyboard shortcut but also a few others such as <Super>+E where "E" is on the physical key "F" and gets mapped to "arrow right". It seems like <Super> is also activating Mod4 in that keyboard layout.

On the other hand, some shortcuts are not affected and work fine, such as <Super>+Q ("Q" is on physical key "P").

This issue has not been present on GNOME 3.0…3.24 on Fedora < 27 but started showing up after I updated to Fedora 27 (GNOME 3.26.1).

Another note: When switching from Neo2 keyboard layout to "normal" German keyboard layout (or English/US layout), <Super>+L acts as if just "L" were pressed, same with <Super>+E. <Super>+Q still works fine in this case.

There has only been one single commit to g-s-d's keyboard plugin in the 3.26 cycle [1], so I am unsure whether g-s-d is to blame at all.

[1] https://git.gnome.org/browse/gnome-settings-daemon/commit/plugins/keyboard?id=d68ef6ad95bd2a5210715feea4ca5112885bec92
https://git.gnome.org/browse/gnome-settings-daemon/log/plugins/keyboard

When changing a different layout as default (e.g. "normal" German keyboard layout), logging out and logging in again, everything works fine. As soon as I switch to the neo2 keyboard layout, it is broken again.

When following these steps:
1. set default layout to "normal" German keyboard layout
2. log out
3. log in
4. wait some seconds until all the apps have been started
5. note the current timestamp
6. switch keyboard layout by using <Super>+Space to Neo2
7. have a look at the logs
I can see only one single warning:

org.gnome.Shell.desktop[2459]: Window manager warning: Overwriting existing binding of keysym 6c with keysym ff52 (keycode 1a).

which is probably related to this bug. FF52 is the "up" key in Xmodmap (see http://wiki.linuxquestions.org/wiki/List_of_Keysyms_Recognised_by_Xmodmap), 6c is ASCII character "l".

The code causing this warning has been added to mutter by Christian Kellner [1] and Jonas Ådahl worked on this code too [2] during the 3.26 cycle, thus I'm adding them to CC.

@Christian Kellner, Jonas Ådahl: Do you have a clue what causes this bug?

I doubt this is a bug in g-s-d, but rather in the keyboard layout or mutter. Feel free to reassign since you probably know better.

[1] https://git.gnome.org/browse/mutter/commit/?h=gnome-3-26&id=68dacb531b2136e792fc510d8ee30a02bc91ee1f

[2] https://git.gnome.org/browse/mutter/commit/?h=gnome-3-26&id=92a53f08f4844f240761852ee6b8448b88048794
https://git.gnome.org/browse/mutter/commit/?h=gnome-3-26&id=487b8a0430cac06535524133f34b6e95748fbb7a
https://git.gnome.org/browse/mutter/commit/?h=gnome-3-26&id=8b060342bd8c8abc348d09b1b71c90a36bc57f05

Hey cool, another guy using Neo! \,,/ {–.–}  \,,/

Thanks for your debug work! Sadly, Neo isn’t (couldn’t be) implemented in a nice manner, but rather (ugly) hacked into xkeyboard-config [1], I already filed a bug there, because of some issues. Seems that this sadly won’t improve in the short term…

[1] https://bugs.freedesktop.org/show_bug.cgi?id=102521&GoAheadAndLogIn=1

And I also filed another bug because of the following output, I often read when starting a GUI program (but I couldn’t find it):

xkbcommon: ERROR: Key "<LFSH>" added to modifier map for multiple modifiers; Using Lock, ignoring Shift

(In reply to Frank from comment #5)
> Hey cool, another guy using Neo! \,,/ {–.–}  \,,/

;)

(In reply to Frank from comment #6)
> And I also filed another bug because of the following output, I often read
> when starting a GUI program (but I couldn’t find it):
> 
> xkbcommon: ERROR: Key "<LFSH>" added to modifier map for multiple modifiers;
> Using Lock, ignoring Shift

I'm seeing that too and I've reported a bug for it too, and I was told there is nothing especially bad about that. I can't find that that bug report though.

Strange. The fixes I made for 3.26 was exactly to avoid these types of issues. Personally I'm using Dvorak/Sv-Dvorak, and hit the issue with newly introduced key bindings colliding (Super+L on dvorak is Super+P on qwerty, which was some monitor configuration thing IIRC). The current semantics is as follows:

1) If the active layout has a-z symbols on the first level, only trigger a keybinding on the current layout
2) If the active layout doesn't have the a-z symbols on the first level, use us-qwerty

2) was needed for users using non-latin layouts (e.g cyrillic)

Maybe something is buggy here, making the 2) being incorrectly triggered

(In reply to Jonas Ådahl from comment #8)
> Strange. The fixes I made for 3.26 was exactly to avoid these types of
> issues.

Interesting, because I didn't have issues with GNOME 3.2 (sic!) through 3.24, only since updating to 3.24. Is the Neo layout broken?

> Personally I'm using Dvorak/Sv-Dvorak, and hit the issue with newly
> introduced key bindings colliding (Super+L on dvorak is Super+P on qwerty,
> which was some monitor configuration thing IIRC). The current semantics is
> as follows:
> 
> 1) If the active layout has a-z symbols on the first level, only trigger a
> keybinding on the current layout
> 2) If the active layout doesn't have the a-z symbols on the first level, use
> us-qwerty
> 
> 2) was needed for users using non-latin layouts (e.g cyrillic)
> 
> Maybe something is buggy here, making the 2) being incorrectly triggered

If there is a way to debug this, please let us know.

I just tried to reproduce by adding the Neo 2 layout locally. Pressing (on a QWERTY keyboard) Super+e successfully locks my screen after having changed to Neo 2.

To debug, I'd go and check when reload_active_keyboard_layouts() is called whether needs_secondary_layout() returns TRUE or not. Then I'd check what  resolve_key_combo() resolves the Super+l key binding to, and see if it makes any sense. Then if that doesn't give any results, see what process_event() in keybindings.c resolves the Super+l keybinding to.

It looks like there is more stuff wrong here introduced with GNOME 3.26.
Steps to reproduce:
1. Have 2 (or more) keyboard layouts, with German as primary and Neo2 as secondary layout for both gnome-shell user and gdm instances.
2. reboot
3. in gdm, switch to Neo2 keyboard layout
4. type a username containing any numbers on Neo2's 4th level

What happens:
Instead of putting numbers (level 4) into the text field, the corresponding keys on level 1 are put in, i.e. "m" instead of 1, "," instead of 2, …

What should happen:
I press the key combination for a number, so it should input the number.

Additional info:
This also works when typing a password. You may want to enable "Text anzeigen" (show text) from context menu.

https://www.neo-layout.org/ shows the neo2 keyboard layout with all its 6 layers, e.g. for how to input numbers.

Is this a separate bug?

(In reply to Jonas Ådahl from comment #10)
> I just tried to reproduce by adding the Neo 2 layout locally. Pressing (on a
> QWERTY keyboard) Super+e successfully locks my screen after having changed
> to Neo 2.
> 
> To debug, I'd go and check when reload_active_keyboard_layouts() is called
> whether needs_secondary_layout() returns TRUE or not. Then I'd check what 
> resolve_key_combo() resolves the Super+l key binding to, and see if it makes
> any sense. Then if that doesn't give any results, see what process_event()
> in keybindings.c resolves the Super+l keybinding to.

Steps I followed to get the details:
0. installed required debuginfo (gnome-shell, mutter, …)
1. Set keyboard layout to default German layout
2. enabled ssh server
3. rebooted
4. logged in to my gnome/wayland session
5. from a different machine, logged in via ssh
5.1. started gdb
5.2. attached gdb to the user instance of gnome-shell
5.3. set the breakpoints (reload_active_keyboard_layouts, resolve_key_combo, needs_secondary_layout)
5.4. `continue`
6. on the test machine, switched the keyboard layout to Neo2 using the gnome-shell top bar indicator.

Debugging this was quite hard as most code is inlined and reordered, i.e. heavily optimized. Anyway, it looks like mutter/core/keybindings.c:763…766 is never called and after returning from reload_active_keyboard_layouts, keys->active_layouts[META_KEY_BINDING_SECONDARY_LAYOUT] is still empty (null pointer) so I *think* `needs_secondary_layout()` returns FALSE.

In reload_combos, MetaKeyBindingManager keys now looks like this:

$5 = {backend = 0x556d513818d0, key_bindings = 0x556d519b1860, key_bindings_index = 0x556d519b1980, 
  ignored_modifier_mask = 18, hyper_mask = 0, virtual_hyper_mask = 1048576, super_mask = 64, 
  virtual_super_mask = 524288, meta_mask = 8, virtual_meta_mask = 262144, overlay_key_combo = {
    keysym = 65515, keycode = 0, modifiers = (unknown: 0)}, overlay_resolved_key_combo = {
    keycodes = 0x556d5314c880, len = 2, mask = 0}, overlay_key_only_pressed = 0, 
  iso_next_group_combo = {{keycodes = 0x556d54294f40, len = 1, mask = 0}, {keycodes = 0x0, len = 0, 
      mask = 0}}, n_iso_next_group_combos = 1, active_layouts = {{keymap = 0x556d540cfcb0, index = 1, 
      n_levels = 8}, {keymap = 0x0, index = 0, n_levels = 0}}, 
  window_grab_modifiers = CLUTTER_MOD4_MASK}

but I don't know how to look at what Super+l resolves to (i.e. get it from the GList). This is as far as I can get:

(gdb) print **keys->key_bindings->keys
Attempt to dereference a generic pointer.

print ((GList)*keys->key_bindings->values)
$10 = {data = 0x556d52adde80, next = 0x556d51a86100, prev = 0x0}



In process_event, with German keyboard layout the the parameter *event looks like this when pressing Super+l:

(gdb) print *event
$2 = {type = CLUTTER_KEY_PRESS, time = 13681111, flags = CLUTTER_EVENT_NONE, stage = 0x55b1a1936ce0, 
  source = 0x55b1a1936ce0, modifier_state = CLUTTER_MOD4_MASK, keyval = 108, hardware_keycode = 46, 
  unicode_value = 108, device = 0x55b1a192c190}


with Neo2, when pressing Super+l (physical: Super+e), It looks like this:

(gdb) print *event
$1 = {type = CLUTTER_KEY_PRESS, time = 116941, flags = CLUTTER_EVENT_NONE, stage = 0x55dadc52c7d0, 
  source = 0x55dadc52c7d0, modifier_state = CLUTTER_MOD4_MASK, keyval = 108, hardware_keycode = 26, 
  unicode_value = 108, device = 0x55dadc521190}

and
resolved_combo.mask = 64 (line 1892)

After running

> binding = get_keybinding (keys, &resolved_combo);

in line 1894, binding has these values:

(gdb) print *binding
$7 = {name = 0x55cb81767a60 "maximize", combo = {keysym = 65362, keycode = 0, 
    modifiers = META_VIRTUAL_SUPER_MASK}, resolved_combo = {keycodes = 0x55cb840ec440, len = 2, 
    mask = 64}, flags = 3, handler = 0x55cb81755ae0}

so resolution went wrong before this line.

I "bisected" some, and found out that the commit introducing the issue was

commit 68dacb531b2136e792fc510d8ee30a02bc91ee1f
Author: Christian Kellner <christian@kellner.me>
Date:   Tue Apr 25 13:17:02 2017 +0200

    keybindings: handle multiple keycodes for keysym
    
    A single keysym can resolve to multiple keycodes. Instead of only using
    the first one and ignoring the others, we store all codes in
    MetaResolvedKeyCombo and then handle all of them in keybinding
    resolution. If we already have bound a keycode for a keybinding with a
    specific keysym then this can get overwritten by a new keybinding with a
    different keysym that resolves to the same keycode. Now that we resolve
    and bind all keycodes for a keysym this might happen more often; in that
    case warn but still overwrite, but only for the first keycode for each
    keysym. If a secondary (i.e. all non-first keycodes) is already indexed
    we just ignore that; this should resemble the old behavior  where we
    only took the first keycode for any keysym as close as possible.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=781223


I also discovered a bug where Wayland and clutter XKB states get out of sync. Will attach a patch for that here later even though it is not really related.

There are also issues preventing Neo2 from being usable in VTE. Some higher layers don’t work there. But I don’t know if this is related to this issue… 

Created attachment 362714 [details] [review]
keybindings: Only add multiple keycodes from the same level

The reason why multiple keycodes could be mapped to a single keysym was
to support having both KEY_FAVORITES and KEY_BOOKMARK map to
XF86Favorites. However, iterating through all layout levels adding all
key codes has severe consequences on layouts with levels that map
things like numbers and arrow. The result is that keybindings that
should only have been added for keycodes from the first level, are
replaced by some unexpected keycode where the same keysym was found on
another level.

An example of this is the up-arrow key and l symbol. Normally you'd find
both the up-arrow symbol and the l symbol on the first level and be done
with it. However, on the German Neo-2 layout, layout level 4 maps the
KEY_E to the l symbol, while layout level 4 maps KEY_E to up-arrow.
Which ever gets to take priority is arbitrary, but for this particular
case KEY_E incorrectly mapped to up-arrow instead of the l symbol,
causing the keyboard shortcut Super+l, which would normally lock the
screen, to trigger the workspace-up (Super+up-arrow) key binding.

-----

I have only tested this on my own setup, but I don't have favorites button nor
a bookmark button as far as I'm aware, so I'm not able to regression test it
regarding the bug that introduced the many-keycodes behavior.

What I have tested is that this fixes the Super+KEY_E on Neo 2 triggering
workspace-up instead of screen lock, and that Super+l on a cyrillic layout
still triggers screen lock.

Another thing I noticed, however, is that combining neo2 and other keyboard
layouts in the same keymap, but on different layout groups, causes issues. It
either seems that libxkbcommon is buggy or something. For example, us-dvorak in
the same keymap as neo 2 but in a different group caused us-dvorak to not have
a properly working modifiers anymore. Typing worked, but thinsg like Ctrl+Shift
were broken. Removing Neo 2 solved the issue. I don't think it has anything to
do with mutter though, as I checked all the modifier states after changing
layout and they looked all correct.

I suggest anyone caring about Neo 2 should open bug. I found these however:

https://bugs.freedesktop.org/show_bug.cgi?id=97024 
https://bugs.freedesktop.org/show_bug.cgi?id=30980
https://github.com/xkbcommon/libxkbcommon/issues/44

I also opened this one:
https://github.com/xkbcommon/libxkbcommon/issues/54

Created attachment 362715 [details] [review]
wayland/keyboard: Don't transfer layout group when replacing xkb state

The layout group determines what actual keyboard layout in the keymap
to use when translating modifier state and key codes to key syms.
When changing a keymap to another, the layout groups has no relation to
the layout groups in the old keymap, thus there is no reason to
transfer it to the new state.

This fixes an issue where the xkb state in meta-wayland-keyboard.c got
desynchronized with the xkb state in clutter-device-manager-evdev.c.

-----

This patch is not very related to the bug report, but something I discovered while debugging.

(In reply to Christian Stadelmann from comment #11)
> It looks like there is more stuff wrong here introduced with GNOME 3.26.
> Steps to reproduce:
> 1. Have 2 (or more) keyboard layouts, with German as primary and Neo2 as
> secondary layout for both gnome-shell user and gdm instances.
> 2. reboot
> 3. in gdm, switch to Neo2 keyboard layout
> 4. type a username containing any numbers on Neo2's 4th level
> 
> What happens:
> Instead of putting numbers (level 4) into the text field, the corresponding
> keys on level 1 are put in, i.e. "m" instead of 1, "," instead of 2, …
> 
> What should happen:
> I press the key combination for a number, so it should input the number.
> 
> Additional info:
> This also works when typing a password. You may want to enable "Text
> anzeigen" (show text) from context menu.
> 
> https://www.neo-layout.org/ shows the neo2 keyboard layout with all its 6
> layers, e.g. for how to input numbers.
> 
> Is this a separate bug?

Yes. FWIW, it seems libxkbcommon might not handle different layouts with "incompatible" modifiers very well. See the xkbcommon bug I reported. I can't test what you describe above however, since my keyboard doesn't have the Mod4 keys.

(In reply to Frank from comment #14)
> There are also issues preventing Neo2 from being usable in VTE. Some higher
> layers don’t work there. But I don’t know if this is related to this issue…

What happens on a regular VT is not related to any of this.

(In reply to Jonas Ådahl from comment #15)
> Created attachment 362714 [details] [review] [review]
> keybindings: Only add multiple keycodes from the same level
> I have only tested this on my own setup, but I don't have favorites button
> nor
> a bookmark button as far as I'm aware, so I'm not able to regression test it
> regarding the bug that introduced the many-keycodes behavior.
Thanks for taking care of this Jonas. I can (regression) test this on Friday (holiday today and PTO tomorrow).

Review of attachment 362715 [details] [review]:

right, this makes it match the clutter evdev layer

Review of attachment 362714 [details] [review]:

makes sense but I can't test it either

(In reply to Jonas Ådahl from comment #15)

Thank you very much for looking into this!

> Created attachment 362714 [details] [review] [review]
> keybindings: Only add multiple keycodes from the same level
> 
> […]
> 
> An example of this is the up-arrow key and l symbol. Normally you'd find
> both the up-arrow symbol and the l symbol on the first level and be done
> with it. However, on the German Neo-2 layout, layout level 4 maps the
> KEY_E to the l symbol, while layout level 4 maps KEY_E to up-arrow.

The the first "layout level 4" should be "layout level 1".


> […]
> https://bugs.freedesktop.org/show_bug.cgi?id=97024

I haven't seen any of the issues described there, just the warning.

> https://bugs.freedesktop.org/show_bug.cgi?id=30980
> https://github.com/xkbcommon/libxkbcommon/issues/54

I haven't seen any of these issues either. From reading your comment I guess they only happen in combination with specific other layouts.


(In reply to Jonas Ådahl from comment #17)
> (In reply to Christian Stadelmann from comment #11)
> > […]
> > Is this a separate bug?
> 
> Yes. FWIW, it seems libxkbcommon might not handle different layouts with
> "incompatible" modifiers very well. See the xkbcommon bug I reported. I
> can't test what you describe above however, since my keyboard doesn't have
> the Mod4 keys.

Ok, reported at https://bugzilla.gnome.org/show_bug.cgi?id=789761.

Comment on attachment 362715 [details] [review]
wayland/keyboard: Don't transfer layout group when replacing xkb state

Attachment 362715 [details] pushed as 08e6aaa - wayland/keyboard: Don't transfer layout group when replacing xkb state

(In reply to Christian Kellner from comment #18)
> (In reply to Jonas Ådahl from comment #15)
> > Created attachment 362714 [details] [review] [review] [review]
> > keybindings: Only add multiple keycodes from the same level
> > I have only tested this on my own setup, but I don't have favorites button
> > nor
> > a bookmark button as far as I'm aware, so I'm not able to regression test it
> > regarding the bug that introduced the many-keycodes behavior.
> Thanks for taking care of this Jonas. I can (regression) test this on Friday
> (holiday today and PTO tomorrow).

*bump* Any progress?

*** Bug 790398 has been marked as a duplicate of this bug. ***

Christian Kellner, could you confirm that the pending bug works as expected?

Ups, that totally fell of my plate. Sorry. Will put it high up on the Todo for today!

Running the patched version currently. Everything seems to work as expected.

Attachment 362714 [details] pushed as 44269e6 - keybindings: Only add multiple keycodes from the same level

Backported to gnome-3-26.