Bug 40751 - Mode_switch assigned both mod1 and mod3. [Was: Small xemacs problems]
Summary: Mode_switch assigned both mod1 and mod3. [Was: Small xemacs problems]
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: XFree86
Version: 1.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: Aaron Brown
Depends On:
TreeView+ depends on / blocked
Reported: 2001-05-15 17:00 UTC by Will Newton
Modified: 2007-04-18 16:33 UTC (History)
3 users (show)

Clone Of:
Last Closed: 2002-08-05 07:50:47 UTC

Attachments (Terms of Use)

Description Will Newton 2001-05-15 17:00:57 UTC
Description of Problem:

termcap seems to have no entry for the emacs terminal type.


start xemacs
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.

Comment 1 Trond Eivind Glomsrxd 2001-05-15 18:21:05 UTC
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?

Comment 2 Will Newton 2001-05-15 18:36:41 UTC
Section "InputDevice"
    Identifier  "Keyboard1"
    Driver      "keyboard"
    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.

Comment 3 Trond Eivind Glomsrxd 2001-05-15 20:33:11 UTC
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 :)

Comment 4 Will Newton 2001-05-15 20:58:52 UTC
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.

Comment 5 Trond Eivind Glomsrxd 2001-06-06 16:22:21 UTC
Reassigning the keymap issue to XFree.

Comment 6 Göran Uddeborg 2001-08-10 19:37:34 UTC
This happens for a Swedish keyboard with XFree86-4.1.0-0.9.4 too.  With my
XF86Config-4 including

        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.)

Comment 7 Daniel Resare 2001-10-26 14:18:26 UTC
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

Comment 8 Mike A. Harris 2002-07-16 09:32:21 UTC
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 xfree86@xfree86.org and xpert@xfree86.org.

Comment 9 Göran Uddeborg 2002-07-26 20:52:44 UTC
Has anybody else reported to XFree86 yet?  If nobody says anything; I'll send a
report shortly.

Comment 10 Göran Uddeborg 2002-08-04 20:34:08 UTC
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.

Comment 11 Mike A. Harris 2002-08-05 07:51:22 UTC
Reopened...  Resolving as RAWHIDE

Comment 12 Göran Uddeborg 2002-08-05 19:59:57 UTC
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.)

Note You need to log in before you can comment on or make changes to this bug.