This forum has been archived. All content is frozen. Please use KDE Discuss instead.

Why aren't my modifications to xkb working?

Tags: None
(comma "," separated)
User avatar
sparhawk
Registered Member
Posts
433
Karma
0
OS
I've asked this question at askubuntu, so feel free to reply there too, if you wuold like the rep :) . I just thought I'd also ask here, just in case KDE was somehow intercepting the xkb keyboard maps.

Short version

Currently, AltGr+- produces ¥. I wish for it to produce an en-dash. In /usr/share/X11/xkb/symbols/us, I replaced all occurances of "yen" with "endash" and restarted, but this made no difference.

For the record:
Code: Select all
$ setxkbmap -query
rules:      evdev
model:      pc104
layout:     us
variant:    altgr-intl
options:    lv3:ralt_switch_multikey,numpad:pc


Longer version

I intially started by looking in /usr/share/X11/xkb/symbols/us, which contains a section marked `xkb_symbols "altgr-intl" {`. This section contains `include "us(intl)"` and `include "level3(ralt_switch)"`, and no mention of AE11 (which is the keycode for `-`).

The section marked `xkb_symbols "intl" {` contains `key <AE11> { [ minus, underscore, yen, dead_belowdot ] };`, and so I modified the yen here in the AltGr position to endash. I restarted and this made no difference, so I tried doing the brute force method as above instead.

More troubleshooting

If I set `setxkbmap -layout us -variant mac`, AltGr+- produces an en-dash as expected (and as defined in the `xkb_symbols "mac" {` section).

I also tried swapping q and w in the `xkb_symbols "basic" {` and `xkb_symbols "intl" {` sections, but this change did not do anything after restarting. I then also tried `setxkbmap -layout us` to select the basic layout, but this also had no effect.

I'm using Kubuntu 13.04.
User avatar
bcooksley
Administrator
Posts
19765
Karma
87
OS
I suspect this is probably because your system is using the newer "rules" system for keyboard rules, which may be using a different file entirely. Try taking a look at /usr/share/X11/xkb/rules/evdev instead.


KDE Sysadmin
[img]content/bcooksley_sig.png[/img]
User avatar
sparhawk
Registered Member
Posts
433
Karma
0
OS
bcooksley wrote:Try taking a look at /usr/share/X11/xkb/rules/evdev instead.


I did have a look at this file, but I'm not really sure what to make of it. There are no direct symbol references in it, and it seems to be more meta-rules. For example, which layout file is associated with which symbol file.
User avatar
bcooksley
Administrator
Posts
19765
Karma
87
OS
Another thing you might want to try is changing to a different layout after modifying your current one, as the current layout is stored as a pre-compiled cached version.


KDE Sysadmin
[img]content/bcooksley_sig.png[/img]
User avatar
sparhawk
Registered Member
Posts
433
Karma
0
OS
Thanks again for the suggestion. I had an inkling that this might have be the case, although I couldn't find any reference to manually rebuilding this cache. However, switching away and then back didn't seem to help.
Code: Select all
$ setxkbmap -query
rules:      evdev
model:      pc104
layout:     us
variant:    altgr-intl
options:    lv3:ralt_switch_multikey,numpad:pc
$ setxkbmap -layout gb
$ setxkbmap -query
rules:      evdev
model:      pc104
layout:     gb
options:    lv3:ralt_switch_multikey,numpad:pc
$ setxkbmap -layout us -variant altgr-intl
$ setxkbmap -query
rules:      evdev
model:      pc104
layout:     us
variant:    altgr-intl
options:    lv3:ralt_switch_multikey,numpad:pc
User avatar
bcooksley
Administrator
Posts
19765
Karma
87
OS
You might also want to take a look at http://ubuntuforums.org/showthread.php?t=1589744 which appears to cover the same issue.


KDE Sysadmin
[img]content/bcooksley_sig.png[/img]
User avatar
sparhawk
Registered Member
Posts
433
Karma
0
OS
Absolutely brilliant bcooksley! Thanks again.

As per the thread deleting /var/lib/xkb/*.xkm then restarting solved the problem.

P.S. You are incredibly knowledgable (and helpful) almost all the time. Is this just from innate knowledge of Linux, or partially from super Google-fu powers? Just because you seem too know much about Ubuntu too, even if it's not your distro. Cheers.
User avatar
bcooksley
Administrator
Posts
19765
Karma
87
OS
Part knowledge, part deduction and part searching.


KDE Sysadmin
[img]content/bcooksley_sig.png[/img]
User avatar
sparhawk
Registered Member
Posts
433
Karma
0
OS
Okay. I think for me, half the problem is knowing what terms to search for. Thanks again.
User avatar
sparhawk
Registered Member
Posts
433
Karma
0
OS
Actually, now I do have a follow-up question that is surely more KDE-based. In /etc/X11/xorg.conf.d/ , I have a few rules. I'm trying to make a general rule for all my keyboards, which is called 10-general-xkb.conf , and a specific rule for my ergonomic keyboard, called 11-TECK-keymap.conf . One difference is that I want most keyboards too swap the ctrl and caps keys, hence 10-general-xkb.conf looks like this:
Code: Select all
Section "InputClass"
  Identifier "Generic keyboards"
  Driver "evdev"
  Option "XKBOptions" "terminate:ctrl_alt_bksp"

  # If you save this file under xorg.conf.d/ :
  Option "AutoServerLayout" "on"

  Option "XkbLayout" "us"
  Option "XkbVariant" "altgr-intl"
  Option "XKbOptions" "lv3:ralt_switch_multikey,numpad:pc,ctrl:swapcaps"
EndSection


(The file 11-TECK-keymap.conf lacks the "ctrl:swapcaps" part.)

However, it seems like the KDE xkb settings apply after the rules in /etc/X11/xorg.conf.d/ . Hence, if the system settings of KDE don't swap the ctrl and caps keys, they are not swapped for generic keyboards. OTOH, if they are swapped in KDE system settings, then they remain swapped for my ergonomic keyboard. It seems like KDE is applying these rules to all keyboards, if I'm interpreting it correctly. Is there a way to tell KDE not to apply its rules? Or apply them with lower priority?

==EDIT==
I tried to Google for this unsuccessfully, but I did find the same problem in Gnome
User avatar
bcooksley
Administrator
Posts
19765
Karma
87
OS
I would suggest unchecking "Configure keyboard options" in System Settings > Input Devices > Keyboard > Advanced, assuming the Control / Caps Lock swap option is located there.


KDE Sysadmin
[img]content/bcooksley_sig.png[/img]
User avatar
sparhawk
Registered Member
Posts
433
Karma
0
OS
Thanks again. It seems like that did *something*, but I'm not sure what exactly. I have an xorg file that matches my ergonomic keyboard, with:
Code: Select all
  MatchIsKeyboard "on"
  MatchProduct "TrulyErgonomic.com Truly Ergonomic Computer Keyboard"


I know that this works, because I have it triggered to activate at-home-modifier, which it does. I've restarted with the following line commented out, and it's clearly activating:
Code: Select all
  Option "TransMod" "36:64"


However, it seems that the basic xkb parts are not getting through. For example this line:
Code: Select all
  Option "XKbOptions" "lv3:ralt_switch_multikey,numpad:pc,ctrl:swapcaps"


I've tried removing ",ctrl:swapcaps" and restarting, but this makes no difference. From `setxkbmap -query`, no options are set.

Oddly enough, I can get this xorg line to function (i.e. I've restarted with the ",ctrl:swapcaps" present and absent) by removing the "MatchProduct" line in the file. (Obviously then it applies to every keyboard, which is not what I want.)

In case it's important, here is my entire xorg file:
Code: Select all
Section "InputClass"
  Identifier "TECK"
  Driver "evdev"

  # If you save this file under xorg.conf.d/ :
  Option "AutoServerLayout" "on"

  MatchIsKeyboard "on"
  MatchProduct "TrulyErgonomic.com Truly Ergonomic Computer Keyboard"

  ### at-home-modifier options begin here.
  # The basic option.
  Option "XkbLayout" "us"
  Option "XkbVariant" "altgr-intl"
  Option "XKbOptions" "lv3:ralt_switch_multikey,numpad:pc,ctrl:swapcaps"
  Option "TransMod" "36:64"
EndSection


===EDIT=== More troubleshooting
Also, I've tried manually changing the settings of they integrated keyboard. First I find the id with `xinput list`, then run
Code: Select all
setxkbmap -device 15 -layout us -variant altgr-intl -option lv3:ralt_switch_multikey,numpad:pc,ctrl:swapcaps

This works as expected.
User avatar
bcooksley
Administrator
Posts
19765
Karma
87
OS
That is quite unusual - I suspect it is probably a bug in X, related to the nesting or application of XKb options.
I'd recommend sticking with your workaround for now.


KDE Sysadmin
[img]content/bcooksley_sig.png[/img]
User avatar
sparhawk
Registered Member
Posts
433
Karma
0
OS
Ah ok. The workaround with `setxkbmap -device` doesn't really work very well, because I want all (normal) keyboards to have their capslock and ctrl swapped, and only my ergonomic keyboards to not. I move around a fair bit with the laptop, using different keyboards, so I guess I could make some udev rules, but it seems a bit too complicated. I guess I'll just manually swap them for now.

Anyway, I also created a bug report here.

Thanks again for all your help.
User avatar
sparhawk
Registered Member
Posts
433
Karma
0
OS
Okay, I've troubleshooted even more! I thought I'd see if higher-level xkb parameters were being blocked by the `MatchProduct` requirement.

I tried changing from the US keyboard layout
Code: Select all
  Option "XkbLayout" "us"

to an Arabic one
Code: Select all
  Option "XkbLayout" "ara"

Initially, I couldn't get this to work, even in the absence of `MatchProduct`. Even though it was set to Arabic, the variant seems odd, and it functioned as a US keyboard.
Code: Select all
$ setxkbmap -query
rules:      evdev
model:      pc105
layout:     ara
variant:    altgr-intl
options:    lv3:ralt_switch_multikey,numpad:pc

I then tried blanking out the variant with
Code: Select all
  Option "XkbVariant" ""

This was then consistent with my previous results. i.e. in the absence of `MatchProduct`, the keyboard was set to Arabic, and in the presence of `MatchProduct`, the keyboard was set to US. Oddly enough, in the latter case, the keyboard was also set to the altgr-intl variant.
Code: Select all
$ setxkbmap -query
rules:      evdev
model:      pc104
layout:     us
variant:    altgr-intl

It seems that somehow,, my keyboard was still being set to the altgr-intl variant. I tried removing the file in /etc/X11/xorg.conf.d altogether, manually setting the keyboard to vanilla US or Arabic with setxkbmap (just in case), then restarting. In both cases, `setxkbmap -query` had the same output as above, listing the altgr-intl variant.

Hence, I wonder if there is a hidden xorg.conf file somewhere in my system? Or perhaps KDE is doing something to set the variant? (As mentioned previously, "Configure layouts" and "Configure keyboard options" are unchecked in System Settings.)

I ran `locate xorg.conf`, which gave the following potential directories:
Code: Select all
/etc/X11/xorg.conf.d
/etc/bumblebee/xorg.conf.d
/usr/share/X11/xorg.conf.d
/usr/share/bumblebee/default-conf/xorg.conf.d


I did `grep altgr-intl -r <path>` and ` grep variant -ir <path>` for each of these, and didn't find any additional mentions apart from the file above.


Bookmarks



Who is online

Registered users: Bing [Bot], claydoh, Google [Bot], rblackwell