I can help debug the wayland error message.

What desktop environment are you using?

Assuming you are using gnome shell, which layouts did you choose exactly, and in what order? (You can see in the "Region & Language" settings).

Did you change any settings in the "Tweak Tool" under "Typing"?

In X11 session, can you show the output of `setxkbmap -print`?

BTW, the keymap usually works fine even with such errors, so it is not necessarily broken. Does it actually not work for you?

> Warning:          Multiple interpretations of "Caps_Lock+AnyOfOrNone(all)"
>                   Using last definition for duplicate fields

> Warning:          Multiple interpretations of "Shift_L+AnyOfOrNone(all)"
>                   Using last definition for duplicate fields

The latter comes from "assign_shift_left_action" in compat/misc, see the comment there why it is required.

I think the proper way to get rid of this warning would be to specify the action associated to a keysym directly, not involving any "Any" patters in the compat, that is, instead of

    interpret Any+Lock {
	action= LockMods(modifiers=Lock);
    };

    interpret Any + Any {
	action= SetMods(modifiers=modMapMods);
    };

(in compat/basic), use

    interpret Caps_Lock {
	action= LockMods(modifiers=Lock);
    };

    interpret Shift_L {
	action= SetMods(modifiers=Shift);
    };
    interpret Shift_R {
        action= SetMods(modifiers=Shift);
    };

This might break some xmodmap setups of those very conservative user still using xmodmap...

> Error:            Key <HYPR> added to map for multiple modifiers
>                   Using Mod2, ignoring Mod4.
> Error:            Key <MDSW> added to map for multiple modifiers
>                   Using Mod3, ignoring Mod5.

The former comes from "modifier_mapping" in symbols/level5, the latter from "lock" in the same file, or something similar.  The purpose is associate the virtual modifiers LevelFive and NumLock to a real modifier, and this is done using keycodes HYPR and MDSW which are known not to be produced by hardware.

A proper fix would be not to use virtual modifiers LevelFive and NumLock (and LevelThree and AltGr) at all, and use real modifiers directly.  This would avoid the need of such hacks as the one in symbols/level5, without any disadvantage.

However, the error messages state that the the modifiers are set up as desired.  From the practical perspective, therefore, there is no pressing need for a change.

(In reply to Ran Benita from comment #1)
> I can help debug the wayland error message.

Thanks.

> What desktop environment are you using?

gnome-shell. Sometimes with wayland, sometimes with x11.

> Assuming you are using gnome shell, which layouts did you choose exactly,
> and in what order? (You can see in the "Region & Language" settings).

German (Neo2)
German (nodeadkeys)
English (US)

> Did you change any settings in the "Tweak Tool" under "Typing"?

I did change some stuff there, but it looks like my changes (keybinding for changing keyboard layout set to "Scroll" key, for example) were deleted. Now it looks exactly like on a fresh user account.
In dconf, everything below /org/gnome/libgnomekbd/desktop, /org/gnome/libgnomekbd/indicator and /org/gnome/libgnomekbd/keyboard is the default value. Same on /org/gnome/desktop/a11y/keyboard.
/org/gnome/desktop/input-sources/xkb-options just lists `['grp:sclk_toggle']`

> In X11 session, can you show the output of `setxkbmap -print`?

xkb_keymap {
        xkb_keycodes  { include "evdev+aliases(qwertz)" };
        xkb_types     { include "complete"      };
        xkb_compat    { include "complete+caps(caps_lock)+misc(assign_shift_left_action)+level5(level5_lock)"   };
        xkb_symbols   { include "pc+de(neo)+de(nodeadkeys):2+us:3+de:4+inet(evdev)+group(sclk_toggle)"  };
        xkb_geometry  { include "pc(pc105)"     };
};


> BTW, the keymap usually works fine even with such errors, so it is not
> necessarily broken. Does it actually not work for you?

Yes, they work for me, I can't see any issues. Since I see errors / warnings (comment #0) I thought I report it anyway.

These are warning message, you can safely ignore them

(In reply to Andreas Wettstein from comment #2)
> > Warning:          Multiple interpretations of "Caps_Lock+AnyOfOrNone(all)"
> >                   Using last definition for duplicate fields
> 
> > Warning:          Multiple interpretations of "Shift_L+AnyOfOrNone(all)"
> >                   Using last definition for duplicate fields
> 
> The latter comes from "assign_shift_left_action" in compat/misc, see the
> comment there why it is required.
> 
> I think the proper way to get rid of this warning would be to specify the
> action associated to a keysym directly, not involving any "Any" patters in
> the compat, that is, instead of
> 
>     interpret Any+Lock {
> 	action= LockMods(modifiers=Lock);
>     };
> 
>     interpret Any + Any {
> 	action= SetMods(modifiers=modMapMods);
>     };
> 
> (in compat/basic), use
> 
>     interpret Caps_Lock {
> 	action= LockMods(modifiers=Lock);
>     };
> 
>     interpret Shift_L {
> 	action= SetMods(modifiers=Shift);
>     };
>     interpret Shift_R {
>         action= SetMods(modifiers=Shift);
>     };
> 
> This might break some xmodmap setups of those very conservative user still
> using xmodmap...

hmm, some Neo2 people are still using xmodmap: https://wiki.neo-layout.org/browser#linux/xmodmap . So just leave this warning be?

> > Error:            Key <HYPR> added to map for multiple modifiers
> >                   Using Mod2, ignoring Mod4.
> > Error:            Key <MDSW> added to map for multiple modifiers
> >                   Using Mod3, ignoring Mod5.
> 
> The former comes from "modifier_mapping" in symbols/level5, the latter from
> "lock" in the same file, or something similar. The purpose is associate the
> virtual modifiers LevelFive and NumLock to a real modifier, and this is done
> using keycodes HYPR and MDSW which are known not to be produced by hardware.
> 
> A proper fix would be not to use virtual modifiers LevelFive and NumLock
> (and LevelThree and AltGr) at all, and use real modifiers directly.  This
> would avoid the need of such hacks as the one in symbols/level5, without any
> disadvantage.
> 
> However, the error messages state that the the modifiers are set up as
> desired.  From the practical perspective, therefore, there is no pressing
> need for a change.

Ok, so these warnings are just "hey, this is not ideal, but it doesn't break so if you don't have a better way, just leave it"?

(In reply to Sergey V. Udaltsov from comment #4)
> These are warning message, you can safely ignore them

Ok. Is there any need to warn then?

> hmm, some Neo2 people are still using xmodmap: https://wiki.neo-layout.org/browser#linux/xmodmap . So just leave this warning be?

The Neo 2 xmodmap would not be affected, I suppose.  But changing the patterns in compat is certainly a change that will not be 100% backward compatible.  To get rid of the warning alone, it is not worth it.  However, in my opinion, if the action of a keysym would only depend on the keysym and not on the modifier map, it would be easier to make non-trivial custom layouts.

> Ok, so these warnings are just "hey, this is not ideal, but it doesn't break so if you don't have a better way, just leave it"?

They are real errors, however, xkbcomp recovers from than in a way that happens to make Neo 2 work.  It's somewhat of a coincidence, but it has been that way for 6-7 years, so practically, its not too fragile.  Again, the messages you see are not a sufficient reason to make big changes.  Making things easier for people that what to make non-trivial custom layouts might be.

i have noticed a related problem: i cannot enter capital letters with the neo (or, in my case adnw) layout. it's probably related to this issue. i have tried replacing the rules in comment #2, but seemingly to no avail (i logged out and back in and nothing had changed).

interestingly, the only programs i've found so far where i *can* enter capital letters are termite (which is an x11 app) and weston-terminal (which is not). it doesn't work in any other app i've tried so far (firefox, chromium, anki, dmenu).

i'm on arch linux, using the sway compositor.

> i cannot enter capital letters with the neo (or, in my case adnw) layout. 

How about non-letter symbols on the shifted layer?  For example, does Shift+1 produce ° as desired?  If it works, if you replace (in adnw_base in symbols/de) EIGHT_LEVEL_ALPHABETIC_LEVEL_FIVE_LOCK by EIGHT_LEVEL_LEVEL_FIVE_LOCK (and make sure to reload the layout), does this help with letters?

(In reply to Andreas Wettstein from comment #9)
> > i cannot enter capital letters with the neo (or, in my case adnw) layout. 
> 
> How about non-letter symbols on the shifted layer?  For example, does
> Shift+1 produce ° as desired?  If it works, if you replace (in adnw_base in
> symbols/de) EIGHT_LEVEL_ALPHABETIC_LEVEL_FIVE_LOCK by
> EIGHT_LEVEL_LEVEL_FIVE_LOCK (and make sure to reload the layout), does this
> help with letters?

Thank you so much! Now typing capital letters works, but setting CapsLock by pressing Shift+Shift still doesn't, unfortunately. I just had a look into types/level5, and for EIGHT_LEVEL_LEVEL_FIVE_LOCK it says that 'Lock has no effect', which I suspect is the reason for that.

The basic error message is still there, by the way:

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

> Now typing capital letters works, but setting CapsLock by pressing Shift+Shift still doesn't, unfortunately. 

If you really followed comment #2 and removed the Any interprets and added the explicit interprets, this surprises me.  Possibly, in symbols/pc and symbols/capslock, you need to remove the lines 'modifier_map Lock { Caps_Lock };'.  It looks like if you press the shift key, apart from the Shift modifer, the Lock modifier is set as well.

> I just had a look into types/level5, and for EIGHT_LEVEL_LEVEL_FIVE_LOCK it says that 'Lock has no effect', which I suspect is the reason for that.

Probably not.  If my hypothesis about Lock being set by pressing shift is right, that Lock has no effect is just the reason that now captial letters work: With EIGHT_LEVEL_ALPHABETIC_LEVEL_FIVE_LOCK, the Lock cancelled the effect of Shift, and with EIGHT_LEVEL_LEVEL_FIVE_LOCK it does not anymore.

> > I just had a look into types/level5, and for EIGHT_LEVEL_LEVEL_FIVE_LOCK it says that 'Lock has no effect', which I suspect is the reason for that.

> Probably not.

I take that back, you are probably right. Does the CapsLock LED light up after Shift+Shift?

Maybe using EIGHT_LEVEL will work better for you, but most likely the price will be that the navigation keys on Level5 will not work properly in some applications when used together with Shift.

[I don't want to hijack this issue, so feel free to ignore me.]

For me, the NEO2 layout didn't work at all in Gnome on Wayland.  My current layout is the dvorak variant of the de layout but I might want to switch to NEO2.  So for testing, I added NEO2 as additional layout in Gnome's Region & Language settings and then after switching to that, everything was completely messed up.

"Completely messed up" meant:

  - the key right of TAB ("q" on QWERTZ) seemed to be backspace
  - the key right of that ("w" on QWERTZ) activated my shell history (so that would usually be Ctrl-r)
  - all other keys also didn't work properly, e.g., many other seem to be backspace, too
  - it looked like with the CapsLock key I could somehow properly activate NEO's layer 6 (except that this layer should not be activated by the CapsLock key)

Then I tried Gnome on Xorg, and NEO2 seemed to work fine.  So I started writing this comment again under Gnome on Wayland.  However, then I recognized that NOW UNDER WAYLAND NEO2 ALSO WORKS.  Huh?  How can that be?  It seems like starting Xorg once (with maybe some machine restarts here and there) fixed NEO2 for Wayland.

>  - the key right of TAB ("q" on QWERTZ) seemed to be backspace
>  - the key right of that ("w" on QWERTZ) activated my shell history (so that would usually be Ctrl-r)

Did you make sure to turn off Num-Lock before switching?  Neo et al repurpose the Mod2 modifier usually used for Num-Lock for Level5-Lock, which can cause some mess.  Pressing what Neo confusingly calls the «Mod4» keys simultaneously should help here.  But I must admit, this attempt for an explanation would fit better if your backspace were on the W key...

>   - it looked like with the CapsLock key I could somehow properly activate
NEO's layer 6 (except that this layer should not be activated by the CapsLock
key)

This would fit to a stuck Mod2.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org'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.freedesktop.org/xkeyboard-config/xkeyboard-config/issues/14.