![]() Registered Member ![]()
|
I've asked this question at askubuntu, so feel free to reply there too, if you wuold like the rep
![]() 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:
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. |
![]() Administrator ![]()
|
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] |
![]() Registered Member ![]()
|
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. |
![]() Administrator ![]()
|
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] |
![]() Registered Member ![]()
|
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.
|
![]() Administrator ![]()
|
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] |
![]() Registered Member ![]()
|
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. |
![]() Administrator ![]()
|
Part knowledge, part deduction and part searching.
KDE Sysadmin
[img]content/bcooksley_sig.png[/img] |
![]() Registered Member ![]()
|
Okay. I think for me, half the problem is knowing what terms to search for. Thanks again.
|
![]() Registered Member ![]()
|
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:
(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 |
![]() Administrator ![]()
|
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] |
![]() Registered Member ![]()
|
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:
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:
However, it seems that the basic xkb parts are not getting through. For example this line:
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:
===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
This works as expected. |
![]() Administrator ![]()
|
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] |
![]() Registered Member ![]()
|
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. |
![]() Registered Member ![]()
|
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
to an Arabic one
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.
I then tried blanking out the variant with
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.
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:
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. |
Registered users: Bing [Bot], claydoh, Google [Bot], rblackwell