Bug 102189

Summary:	Level 5 switches yield NoSymbol without a Level 5 lock simultaneously enabled
Product:	xorg	Reporter:	Socialdarwinist <socialonyourdesktop>
Component:	Server/Input/XKB	Assignee:	Xorg Project Team <xorg-team>
Status:	RESOLVED MOVED	QA Contact:	Xorg Project Team <xorg-team>
Severity:	normal
Priority:	medium
Version:	unspecified
Hardware:	All
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:

Description Socialdarwinist 2017-08-12 21:06:05 UTC

Set a keyboard layout that uses more than four levels. This is a generic Cyrillic layout I have created to mitigate the four-layout limitation in XKB: https://gist.github.com/Socialdarwinist/82c9db494f706bfeb3ea5918b5a1ca69

If you enable a level 5 switch, no matter if it is already present, like for example level5(lsgt_switch), or created like in my pan-Cyrillic keyboard layout for the Caps Lock key, no matter if in the desktop environment or in the xorg.conf, you will nonetheless be unable to type in anywhere any of the characters only reachable via the level 5 modifier – unless you also enable any of the locks present in the symbols/level5 file, for example level5(rwin_switch_lock).

It is notable that xev correctly reports the key set as a level 5 switch as ISO_LEVEL5_SHIFT, even though using it yields NoSymbol.

It is interesting that the level 5 switches are also not presented in the rules/base file (respectively rules/base.o_s.part in the git repository) unlike the level 5 locks and all the level 3 modifiers. It suggests that somebody has already noticed that the level 5 switches do not work but has absconded from reporting it and leading it to a fix.

I have reproduced the bug by setting the keyboard layout desktop-environment-internal, i.e. via libgnomekbd in Cinnamon and libmatekbd in MATE, as well as in an xorg.conf, therewith even in twm. I have reproduced the bug likewise on different machines, one Antergos Linux on a 64-bit Intel machine, the other pure Arch Linux on a 64-bit AMD machine.

I advance the question if I should still publish the keyboard layout even with this bug present if I include level5(rwin_switch_lock) as a workaround. I think yes. Nobody fixes anything anyway in the XKB, correct?

Comment 1 Socialdarwinist 2017-08-16 21:39:25 UTC

I have found similar errors that make the matter look really nasty:

In the following four keys which I have inserted in the pan-Cyrillic keyboard layout at the time of writing this only offered at my GithubGist (revision 19) the last two characters of each key do not appear, and it continues to be the last two letters if I regroup the letters inside one of the key’s mapping:

key <AD04> {[Cyrillic_ka, Cyrillic_KA, Cyrillic_ka_descender, Cyrillic_KA_descender, U049F, U049E, U046F, U046E]}; // к К Қ қ ѯ Ѯ ҟ Ҟ
key <AB02> {[Cyrillic_che, Cyrillic_CHE, Serbian_tshe, Serbian_TSHE, UA65B,    UA65A, U04B7, U04B6]};	                             // ч Ч ћ Ћ ꙛ Ꙛ ҷ Ҷ
key <AB03> {[Cyrillic_es, Cyrillic_ES, U046D, U046C, U046B, U046A,                                  Cyrillic_che_vertstroke, Cyrillic_CHE_vertstroke]}; // с С ѭ Ѭ ѫ Ѫ ҹ Ҹ
key <AB05> {[Cyrillic_i, Cyrillic_I, U0475, U0474, U048B, U048A, U04CC, U04CB]}; // и И ѵ Ѵ ҋ Ҋ ӌ Ӌ

You are invited to express your suspicions about the cause of this bug, for it has made me sick.

Comment 2 Socialdarwinist 2017-08-20 16:14:03 UTC

Well, including level5(rwin_switch_lock) does not work. It must be configured for the whole desktop in the xorg.conf or dconf to make level5(caps_switch) work.

Also I have tested the number row for combinations not working. key <AE02> and key <AE06> do not work in the seventh and eighth level. I have already reordered many keys, but it’s without influence. It continues to be the same positions.

Comment 3 Socialdarwinist 2017-08-20 18:04:57 UTC

I have now tested all keys in order to have the layout ready for publication, and I have found out that the key <AE03> does not work at the fourth (!) level, the sixth level and the eighth level.

Comment 4 Socialdarwinist 2017-08-20 20:39:47 UTC

Testing on the pure Arch Linux machine, there are no gaps though, only the issue described in the original post is on it.

Comment 5 Socialdarwinist 2017-08-21 20:21:39 UTC

It does not seem to be a driver issue. I have used libinput on the Antergos machine originally, now I have tested the layout with evdev and obtained the stated results.

Comment 6 Socialdarwinist 2017-08-21 20:28:23 UTC

On the Antergos machine I have even reproduced it on a Fedora VM. Exactly the same keys lack. And the fourth character of the 3 key in the default German layout does not work either. Probably the keyboard is bad.

Comment 7 Socialdarwinist 2017-09-12 20:56:34 UTC

Oh yeah, nobody does fix things in XKB – there is an analogous bug report from 2008 https://bugs.freedesktop.org/show_bug.cgi?id=19311 with a link to further discussions on launchpad begun in 2006 (which I haven’t found in the beginning because it is filed for the component Input/Keyboard instead of Server/Input/XKB).

Comment 8 Socialdarwinist 2017-11-20 16:36:59 UTC

With having now a new physical keyboard, all key combinations listed work. So I conclude that it has been a hardware issue, for the record with Sharkoon Skiller Pro.

However of course the original issue is still the case as it is reproduced on multiple systems:
“Level 5 switches yield NoSymbol without a Level 5 lock simultaneously enabled”

Comment 9 GitLab Migration User 2018-12-13 18:39:27 UTC

-- 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/xorg/xserver/issues/317.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.