German Neo2 Problem with Xubuntu 18.04 (try out mode)

Bug #1783987 reported by Krino Hoogestraat on 2018-07-27
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
xkeyboard-config
Unknown
Low
xkeyboard-config (Ubuntu)
Undecided
Unassigned

Bug Description

When trying Xubuntu 18.04 Bionic Beaver from a USB Stick, I am offered the Neo2 Keyboard Layout, but it does not work. What I get is apparently Neo2 Mod4, but not Mod 1, as it should be.

I wonder if Neo2 does work if I install 18.04 properly?

I'm using the keyboard layout de-neo (German Neo2). When starting a x11 graphical application in a xwayland session, I see this error message printed to console or syslog:

The XKEYBOARD keymap compiler (xkbcomp) reports:
> Error: Key <LFSH> added to map for multiple modifiers
> Using Lock, ignoring Shift.
Errors from xkbcomp are not fatal to the X server

When starting wayland graphical applications (using Gtk+ 3.20) I get this message:

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

When starting a x11 session I get this message:

The XKEYBOARD keymap compiler (xkbcomp) reports:
> 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
> 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.
Errors from xkbcomp are not fatal to the X server

So it looks like this layout is broken. I have no idea what. Can you please give me a hint on the reason why this happens?

Upstream is at https://wiki.neo-layout.org/browser#linux/X/rules, but they don't seem to fix these warnings/errors: https://wiki.neo-layout.org/ticket/408

I'm running Fedora 24 with
xkeyboard-config-2.17-2.fc24.noarch
libxkbcommon-0.6.1-1.fc24.x86_64

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.

Gunnar Hjalmarsson (gunnarhj) wrote :

I think Neo 2 is it, but it's a complex keyboard layout. There are some hints in the file

/usr/share/X11/xkb/symbols/de

If you need help to understand how it's supposed to be used, please use one of the support resources, e.g. <https://askubuntu.com>.

There does not seem to be a bug here, so closing.

Changed in xkeyboard-config (Ubuntu):
status: New → Invalid
Krino Hoogestraat (krino) wrote :

Thanks Gunnar :-)

I don't think my report was invalid. I've been using Neo 2 for many years, so I know what it looks like when it works. So here's what happens in some more detail:

1. I insert a USB Stick with xubuntu-18.04-desktop-amd64.iso into my computer.
2. I start the computer and, by pressing F10, use the USB as my booting device (live system).
3. I select Language Deutsch.
4. I select »Ubuntu ausprobieren« (try Ubuntu).
5. In the keyboard menu, I change from »Deutsch qwertz« to »Deutsch Neo 2«.
From here, the keyboard should respond in the Neo manner, meaning that asdf yields uiae, jklö yields nrtd, etc. At least that's what it does when using 16.04.
6. I start Mousepad to test the keyboard layout. So jklö should yield nrtd, but in actual fact what I get is ›456,‹. Which is Neo 2 to be sure, however it's not Mod1, but Mod4.

Gunnar Hjalmarsson (gunnarhj) wrote :

I jumped at conclusions; sorry for that.

I too see the issue you mention. However, I found an upstream bug report, and one of the ideas mentioned there was to disable NumLock. Once I had done so, the "German (Neo 2)" layout seemed to behave as expected.

Can you please make sure that NumLock is turned off when switching to Neo 2 and let us know if that helps.

Changed in xkeyboard-config (Ubuntu):
status: Invalid → Incomplete
Changed in xkeyboard-config:
importance: Unknown → Low
status: Unknown → Confirmed
Krino Hoogestraat (krino) wrote :

Gunnar:
Can you please make sure that NumLock is turned off when switching to Neo 2 and let us know if that helps.

***

I tried that, and as you predicted, with NumLock turned off, the Neo 2
keyboard behaves normally.

Does that mean I can go ahead and install 18.04, and everything will be
fine?

Gunnar Hjalmarsson (gunnarhj) wrote :

There is no reason to expect anything else. A live session and a fully installed system should behave identically in this respect. My own testing was on a fully installed Ubuntu 18.04.

Changed in xkeyboard-config (Ubuntu):
status: Incomplete → Confirmed
Krino Hoogestraat (krino) wrote :

Fine, thanks for that.

As I use Neo 2 exclusively – no other keyboard layouts – there should be no further problems once the choice has been made.

-- 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.

Changed in xkeyboard-config:
status: Confirmed → Unknown
Benjamin Fischer (reducedbeta) wrote :

In my case, what helped was to remove package `numlockx` with `sudo apt-get purge numlockx`.

This package `numlockx` was integrated into Xubuntu's startup with version 18.04 (see https://wiki.xubuntu.org/releases/18.04/release-notes#numlock). It always turns on Num Lock on startup, which is related to the Neo keyboard layout behaving weirdly as others mentioned above.

With that I can use 2 keyboard layouts. I hope this helps others.

Martin Beeger (martin-beeger) wrote :

Deactivating numlock before activting neo2 also fixed this issue for me.

So it is an interference between those two.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.