bar ('|') is not working when using # setxkbmap "cz,us" Warning! Multiple definitions of keyboard layout Using command line, ignoring X server Trying to build keymap using the following components: keycodes: xfree86+aliases(qwertz) types: complete compat: complete symbols: pc+cz+us:2+group(shifts_toggle) geometry: pc(pc105) but it does when using # setxkbmap "us,cz" Warning! Multiple definitions of keyboard layout Using command line, ignoring X server Trying to build keymap using the following components: keycodes: xfree86+aliases(qwerty) types: complete compat: complete symbols: pc+us+cz:2+group(shifts_toggle) geometry: pc(pc105) So it depends on the order. This is xkeyboard-config 0.9 on X.Org 7.2 RC1.
Created attachment 7548 [details] xmodmap -pke for cz,us
Created attachment 7549 [details] xmodmap -pke for us,cz
Created attachment 7550 [details] Diff us,cz --> cz,us
Czech keyboard layout: http://www.uni-regensburg.de/EDV/Misc/KeyBoards/#TschechischQWERTY
Created attachment 7552 [details] [review] Braindead patch, which seems to fix this issue
Stefan, it looks like you want setxkbmap -layout cz,us -variant bksl,
Thanks for the hint!
So, are we closing this one?
Yes.
The same problem applies to "no,us" (Norwegian/U.S.), and "fr,us" (French/U.S.). This works: setxkbmap -layout 'us,no' -option -option 'grp:alts_toggle' This does not: setxkbmap -layout 'no,us' -option -option 'grp:alts_toggle' In the latter case, the backslash/pipe key will always stick to the Norwegian layout (single-quote/asterisk). All other keys are correctly remapped. If "no" is exchanged with "fr", the same problem comes up in the latter case: The backslash/pipe key will stick to the french layout (asterisk/mu), even when toggling groups.
The problem happens because we always have symbols/pc put into the first group (before any other symbols). That's where original BKSL keycode is mapped to pipe and backslash. If in the first group we have layout which redefines BKSL (like 'no') - the backslash and pipe get overridden. And if in other, higher (2 etc) groups it is not defined explicitly (like in 'us') - it just uses whatever mapping exists in the first group ('no') in our case. If first group contains layout which does not have BKSL remapped (for example, 'us') - its mapping is taken from symbols/pc. And all higher groups use that mapping unless they override BKSL mapping explicitly (like 'no'). So, the only solution I see is trying to add symbols/pc to every group we are going to have in our configuration. Lads, what do you think on this?
Actually I think we'll fix it the simplest possible way...
*** This bug has been marked as a duplicate of bug 10811 ***
There are 2 ways: * include symbols/pc in all layouts * move keys away from symbols/pc if they are not identical within all layouts I am not sure whether the 1st solution is safe for non-PC keyboards, so I prefer the 2nd one. BTW <CAPS> needs also to be considered, because it is redefined in symbols/jp.
Denis, I think #10811 fixes it for many layous (based on 'us'). Once/If we get more reports, we'll add BKSL to other layouts. That way we'll eventually implement your #2. Is this reasonable?
Sure, please add CAPS as well into symbols/us.
sure!
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.