Bug 91042 - inet(evdev) blindly overrides some of the keys: <MUHE>, <HENK>, <HKTG> and many others
Summary: inet(evdev) blindly overrides some of the keys: <MUHE>, <HENK>, <HKTG> and ma...
Status: RESOLVED MOVED
Alias: None
Product: xkeyboard-config
Classification: Unclassified
Component: General (show other bugs)
Version: unspecified
Hardware: All Linux (All)
: medium normal
Assignee: xkb
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-06-20 23:12 UTC by Alex-Daniel Jakimenko
Modified: 2018-12-28 00:37 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Alex-Daniel Jakimenko 2015-06-20 23:12:27 UTC
I have a japanese keyboard that has additional keys (henkan, muhenkan, hiragana_katakana – keycodes 100, 102 and 101) and I want to remap these keys to something different.

I have created a completely new symbol file (without any includes) with these lines:

key <MUHE> { [ a, b ] };
key <HENK> { [ c, d ] };
key <HKTG> { [ e, f ] };

But it is not working fully. Here is what happens:
* If I press MUHE then nothing is typed in, xev reports that Muhenkan was pressed (which is wrong, it should be mapped to "a")
* If I press Shift+MUHE then letter "b" is typed in – correct! This means that there is no error in my config.
Exactly the same thing happens with the other keys – bare key is not remapped, but shift+key works correctly.

Since I can remap any other key (alt, ctrl, whatever) without any problems, and since I can set shift+<henk|muhe|hktg> keys correctly, I am suspecting that it is a bug in xkb.

For now, the workaround is to use xmodmap:
xmodmap -e 'keycode 100 = a'

I was struggling with this problem for two days, there is almost no information on that topic, but it seems like there is another mention of this problem here: http://ubuntuforums.org/showthread.php?t=966384&p=6087155#post6087155
Comment 1 Alex-Daniel Jakimenko 2015-06-21 00:25:25 UTC
And all of sudden I figured it out myself. Look:
$ setxkbmap ef -print
xkb_keymap {
	xkb_keycodes  { include "evdev+aliases(qwerty)"	};
	xkb_types     { include "complete"	};
	xkb_compat    { include "complete+ledcaps(group_lock)"	};
	xkb_symbols   { include "pc+ef+inet(evdev)"	};
	xkb_geometry  { include "thinkpad(intl)"	};
};

The most important part is this: "pc+ef+inet(evdev)"

So I guess it loads up pc, then ef (my layout), then inet(evdev). No matter how hard I try to set something in ef it will be overriden from inet(evdev). The only way to solve it is to comment out these lines in inet (under evdev section, of course):
    key <HKTG>   {      [ Hiragana_Katakana     ]       };
    key <HENK>   {      [ Henkan                ]       };
    key <MUHE>   {      [ Muhenkan              ]       };
It works! Hooray!


Now, this is wrong. It should be possible to modify any key from the layouts, I don't think there is any reason to hardcode some of the keys by overriding them.

So the issue is still there, it is just a bit different from what I thought initially. I'll change the title of this report.
Comment 2 Benno Schulenberg 2015-11-07 13:54:40 UTC
How about overriding inet after it has been read?  So, instead of having "pc+ef+inet(evdev)" you would have "pc+ef+inet(evdev)+special(lettering)", where the symbols/special file contains this:

partial
xkb_symbols "lettering" {
key <MUHE> { [ a, b ] };
key <HENK> { [ c, d ] };
key <HKTG> { [ e, f ] };
};

Sure, your nice keyboard layout will not be in a single file any more, but at least you don't have to change system files (that may get overwritten by an update).
Comment 3 Sergey V. Udaltsov 2015-11-08 12:24:44 UTC
For that, you can even introduce XKB option and add it to the rules.
Comment 4 GitLab Migration User 2018-12-28 00:37:00 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/xkeyboard-config/xkeyboard-config/issues/50.


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.