Keyboard layout being overwritten? [SOLVED]

[kuadrat]

Hi all,

so my idea was to configure my keyboard layout to better suit my needs.
To that end, I edited the file /usr/share/X11/xkb/symbols/us.
For the sake of example, I edit the first entry - the tilde key - from the original:

Code: Select all

key <TLDE> { [ grave, asciitilde]}; 

to the new

Code: Select all

key <TLDE> { [ 1, 2, 3, 4]}; 

.

With the original layout, if I press the sequence <TLDE>, <SHIFT>-<TLDE>, <ALT>-<TLDE>, <SHIFT>-<ALT>-<TLDE> I got the following output:

Code: Select all

`~àþ

After a

Code: Select all

setxkbmap -layout us

, I get the following:

Code: Select all

12±²

.

So the first two entries come out as expected from the customized layout file, while the second two have changed to something completely different.
And the same is true for any key I have tried, so it's not just the TLDE key.
(For completeness sake, I add the example of changing

Code: Select all

key <AC01> { [ a, A]}; 

to

Code: Select all

key <AC01> { [ a, A, adiaeresis, Adiaeresis]}; 

which, in both cases, produces:

Code: Select all

aAáÁ

Code: Select all

$ setxkbmap -verbose 10 -layout us
Setting verbose level to 11
locale is C
Warning! Multiple definitions of keyboard layout
         Using command line, ignoring X server
Trying to load rules file ./rules/evdev...
Trying to load rules file /usr/share/X11/xkb/rules/evdev...
Success.
Applied rules from evdev:
rules:      evdev
model:      pc105
layout:     us
options:    terminate:ctrl_alt_bksp
Trying to build keymap using the following components:
keycodes:   evdev+aliases(qwerty)
types:      complete
compat:     complete
symbols:    pc+us+inet(evdev)+terminate(ctrl_alt_bksp)
geometry:   pc(pc105)

Neither pc, inet(evdev) nor terminate seem to contain anything that would overwrite the usual keys.

Code: Select all

$ cat /etc/default/keyboard
# KEYBOARD CONFIGURATION FILE

# Consult the keyboard(5) manual page.

XKBMODEL="pc105"
XKBLAYOUT="us"
XKBVARIANT=""
XKBOPTIONS="terminate:ctrl_alt_bksp"

BACKSPACE="guess"

I have tried to reconfigure with dpkg-reconfigure keyboard-configuration and console-setup as suggested by the Wiki, but that does not seem to be the issue here.
My guess is that it might have something to do with the "Warning! Multiple definitions of keyboard layout
Using command line, ignoring X server"
and/or the fact that setxkbmap prints the locale as C when $LANG is en_GB.UTF-8.

Is it possible that some other application is overwriting the xkb setup?
I am running debian 10 (buster) with openbox.
Thanks already for your time in reading! Any help is appreciated!
Cheers!

[Head_on_a_Stick]

Code: Select all

localectl

[kuadrat]

Code: Select all

$ localectl   
System Locale: LANG=en_GB.UTF-8
                  LANGUAGE=en_GB:en
       VC Keymap: n/a
      X11 Layout: us
       X11 Model: pc105
     X11 Options: terminate:ctrl_alt_bksp

[kuadrat]

The en_GB locale motivated me to look in the file /usr/share/X11/xkb/symbols/gb but nothing in there seems to explain the observed behaviour.

In fact, I have made another puzzling (at least to me) observation:
My <q> key produces (<q>, <SHFT>-<q>, <ALT>-<q>, <ALT>-<SHFT>-<q>):

Code: Select all

qQñÑ

.
According to the us layout file, the q key is called <AD01>.
However, no file in /usr/share/X11/xkb/symbols assigns ntilde and Ntilde to <AD01>:

Code: Select all

$ grep "AD01.*ntilde" *
grep: digital_vndr: Is a directory
grep: fujitsu_vndr: Is a directory
grep: hp_vndr: Is a directory
grep: jolla_vndr: Is a directory
grep: macintosh_vndr: Is a directory
grep: nec_vndr: Is a directory
grep: nokia_vndr: Is a directory
grep: sgi_vndr: Is a directory
grep: sharp_vndr: Is a directory
grep: sony_vndr: Is a directory
grep: sun_vndr: Is a directory
grep: xfree68_vndr: Is a directory
$
$ grep "AD01.*ntilde" */*
$

[Head_on_a_Stick]

Revert all the changes you have made to system files, not sure why you edited those at all, then try

Code: Select all

# dpkg-reconfigure keyboard-configuration locales

[kuadrat]

Thanks for the input!

The reason I edited these system files is because I would like to customize my keyboard layout to suit my needs.
(Concretely, I want to access the Umlaute ä, ö, ü and some other special characters, as well as have z and y keys switched, but use the US keyboard layout otherwise.)
Though I realize it's not ideal to do this via manual editing of system files, this has worked for me on openSUSE and I have not found another way to do this yet. I'm open for suggestions though!

In some sense, my question is also fueled by curiosity: I have confirmed that the `us` layout file is loaded by editing it and the changes for level 1 keys being reflected as expected. Then, at the same time, the level 2 keys do not match what I specify in the `us` file and, in fact, none of these files explain the observed behaviour, so I'm wondering about the mechanism of how the final keymap is assembled.

I've tried `dpkg-reconfigure keyboard-layout locale` suggestion but it doesn't seem to me that it'll help me achieve my goal.

[L_V]

Not sure it's a good idea to modify default keyboard files.
You can copy us file to us_custom or zz file, and modify this new one.

The keyboard configuration in console and X modes are not the same.
See this:

Code: Select all

cat /etc/default/keyboard
cat /etc/default/console-setup
cat /usr/share/console-setup/keyboard 

+ in X environment, you can try 'setxkbmap xx' to check any change (ref to man setxkbmap)

[kuadrat]

Not sure it's a good idea to modify default keyboard files.
You can copy us file to us_custom or zz file, and modify this new one.

That is good advice to give, indeed! I have made a backup before messing with these files, of course.

The keyboard configuration in console and X modes are not the same.

That's interesting, thanks for pointing it out! I'll see if that is at the root of the issue. On first glance, it doesn't look like it.

+ in X environment, you can try 'setxkbmap xx' to check any change (ref to man setxkbmap)

Thanks for the advice. This is indeed what I've been using to test my changes. But the manpage you referred me to has eventually led me tothis ArchLinux forum.

I used `xkbcomp` to (supposedly) output the complete .xkb file that is in use.
Again, I haven't found anything that explains the mappings that I actually observe and editing the config and uploading with xkbcomp reproduces the observations described in the original post...

One of the manpages I skimmed through spoke of "default kernel accent tables", I'll look into that next...

[L_V]

To that end, I edited the file /usr/share/X11/xkb/symbols/us.

May be this one is concerned

Code: Select all

/usr/share/keymaps/i386/qwerty/us.kmap.gz

[kuadrat]

To that end, I edited the file /usr/share/X11/xkb/symbols/us.

Correct, but I *did* make a backup of that file

Thanks for another valuable hint!
/usr/share/keymaps did not exist on my system. It's provided by the console-data package. I installed that to check, but reproduced the behaviour from the original post, so I uninstalled again as I don't think having more things that do similar things will help us shed light on what's going on.

[kuadrat]

Dear all,

thanks again for the hints and suggestions thus far. Another helpful comment on stackoverflow finally resolved this issue for me.

The confusion arose because vim (and apparently bash as well) treat the ALT key as "invert the 8-th bit", therefore creating characters that differ from what is defined in the xkb symbols files.

Using right-alt instead, the xkb configuration works as expected.

---

For completeness and in the hope that it might help somebody in the future, I add the steps undertaken in order to get the Umlaute äöü easily accessible by <RIGHT-ALT>-<A/O/U>:

1. Created a backup of the file /usr/share/X11/xkb/symbols/us (I named it us.bk)
2. Edited the "us" file as follows:

Code: Select all

$ diff us us.bk
124c104
<     key <AD01> { [	   q,          Q,        aacute,           Aacute ] };
---
>     key <AD01> { [	   q,          Q,    adiaeresis,       Adiaeresis ] };
129,130c109,110
<     key <AD06> { [	   z,          Z,        uacute,           Uacute ] };
<     key <AD07> { [	   u,          U,    udiaeresis,       Udiaeresis ] };
---
>     key <AD06> { [	   y,          Y,    udiaeresis,       Udiaeresis ] };
>     key <AD07> { [	   u,          U,        uacute,           Uacute ] };
132,133c112,113
<     key <AD09> { [	   o,          O,    odiaeresis,       Odiaeresis ] };
<     key <AD10> { [	   p,          P,        oacute,           Oacute ] };
---
>     key <AD09> { [	   o,          O,        oacute,           Oacute ] };
>     key <AD10> { [	   p,          P,    odiaeresis,       Odiaeresis ] };
137c117
<     key <AC01> { [	   a,          A,     adiaeresis,       Adiaeresis] };
---
>     key <AC01> { [	   a,          A,        aacute,           Aacute ] };

i.e. just switch the [aou]diaeresis parts with the respective parts on the [aou] keys. I did this in the keyboard variant "intl".
3. Load the keyboard configuration with the right variant:

Code: Select all

$ setxkbmap -rules -evdev -model -evdev -layout us -variant altgr-intl

(the "altg-intl" variant loads the "intl" variant which we edited before)