Red Hat Bugzilla – Bug 40751
Mode_switch assigned both mod1 and mod3. [Was: Small xemacs problems]
Last modified: 2007-04-18 12:33:15 EDT
Description of Problem:
termcap seems to have no entry for the emacs terminal type.
Tools -> Shell...
unknown terminal "emacs"
unknown terminal "emacs"
When xemacs starts up I get this warning:
(1) (key-mapping/warning) XEmacs: Mode_switch (0x71) generates both
Mod1 and Mod3, which is nonsensical.
I mentioned these to an xemacs team member and he suggested they were
a distribution issue.
XEmacs shouldn't set terminaltype to "emacs", it should use "dumb". As for the
mode_switch issue, that would be related to X... what does your keyboard section
in X look like?
Option "AutoRepeat" "500 20"
Option "XkbRules" "xfree86"
Option "XkbModel" "pc105"
Option "XkbLayout" "gb"
I'm running KDE from Rawhide also, if that is relevant.
I can't find any way to set the term type within xemacs.
The modifiers is an X issue (try setting "102" keys there to get rid of this
message) - I've not yet found where xemacs sets terminal to "emacs" (or any
reason for doing it... - it's broken behaviour. Try GNU Emacs instead :)
Using Xkeycaps I can fix the modifier key problem - Alt Gr is configured to
MOD_1 and MOD_2 - resetting to default 105 key UK keyboard makes it work
I'll talk to the xemacs people about the terminal type settings.
Reassigning the keymap issue to XFree.
This happens for a Swedish keyboard with XFree86-4.1.0-0.9.4 too. With my
Option "XkbLayout" "se"
Option "XkbModel" "pc104"
I get a modifier setting looking like this:
xmodmap: up to 2 keys per modifier, (keycodes in parentheses):
shift Shift_L (0x32), Shift_R (0x3e)
lock Caps_Lock (0x42)
control Control_L (0x25), Control_R (0x6d)
mod1 Alt_L (0x40), Mode_switch (0x71)
mod2 Num_Lock (0x4d)
mod3 Mode_switch (0x71)
mod4 Super_L (0x73)
mod5 Scroll_Lock (0x4e)
Mode_switch should only belong to mod3. I think, but am not positive, this has
happened sometime after 4.0.1-1. (I didn't have any problems before I
upgraded. But I can't easily go back to verify at the moment.)
I've done some investigation on this (w/o any documentation whatsoever of the
file format used in /usr/X11R6/lib/X11/xkb/) and it seems like the following
<RALT> is defined to Alt_R, Meta_R (symbols/us:178)
Mod1 is defined to Alt_L, Alt_R, Meta_L, Meta_R (symbols/us:181)<RALT> is
redefined to Mode_switch (symbols/en_US:35)
Mod2 is defined to Mode_switch (symbols/en_US:42)
the relationship between us and en_US seems to be defined by the statment
'augment "us(pc105)"' that I don't know the meaning of, but it seems impossible
to redefine the modifier_map for Mod1 once it is defined. So the solution as I
see it, without serious XKB code hacking is to remove the modifier_map from
symbols/us:181. The only side effect this would have is that when using the
pc105 Shift-AltGR wouldn't behave the same as AltGR.
The real fix of course is to really understand what is happening and remove
Mode_switch from Mod1 when it is used in Mod3
I've investigated this a bit, and am unable to find a solution which
works properly. I'm no expert in this particular area any more than
any of you are, so it is something that should be reported upstream
to XFree86.org, and fixed in the upstream release by someone more
familiar with manipulating these files. They'll likely be able to fix
it more promptly and correctly, and we can then pick up the fix from
the next XFree86 release.
Please report to firstname.lastname@example.org and email@example.com.
Has anybody else reported to XFree86 yet? If nobody says anything; I'll send a
When checking, this doesn't seem to happen any more with XFree86 4.2. I guess
it was fixed upstreams, so I won't report anything.
Reopened... Resolving as RAWHIDE
You could probably even had done CURRENTRELEASE. 7.3 had XFree86 4.2. (I
haven't verified it on a pure 7.3 system, though.)