garyo@THINK.COM (Gary Oberbrunner) (01/09/90)
I'm running vanilla R4 on a color Sun 4/110. The tests I describe below
are with no window manager, no resource database, just straight
out-of-the-box X.
The major symptom is that my shell (tcsh), which runs in cbreak mode and
eats 8-bit characters (hi bit == META), doesn't work properly with xmodmap
and xterm. Here's the scenario:
- Fire up X with vanilla xinit, nothing extra. Get an xterm.
- Fire up a couple more xterms (all these are running tcsh).
: At this point, all the xterms accept control and meta chars.
- run xmodmap with the following map:
remove lock = Caps_Lock
remove mod1 = Meta_L
remove mod1 = Meta_R
add mod1 = Caps_Lock
add mod1 = Alt_R
add control = Meta_L
add control = Meta_R
: Now, all the existing xterms have their keys rebound to the new
control and meta keys. So far just fine.
- Start up a new xterm.
: This new xterm doesn't accept any control keys (it just beeps, as if
it weren't actually seeing the keys I'm typing but something else
instead), and the meta keys do nothing - unaldulterated normal keys
come out instead (M-f inserts an f).
- Any new xterms started up now will have this problem.
If I start up 'cat' and type at it, things seem fine (no meta chars,
of course). The control chars appear fine. Ditto with vi. Emacs running
in the new xterm window (the one with the trashed meta, etc.) seems to
think that the caps lock has been turned off, but (strangely) my
control key AND the old meta key have been turned into control-meta
keys! No wonder tcsh is barfing, if indeed that's the story. It's
getting all these meta chars when I think I'm typing controls. So it's
as if the xmodmap worked partially or something. What gives?
All this stuff worked like a charm under R3. What is different?
Could it be related to the insert-eight-bit and insert-seven-bit actions?
I tried various combos of those, but nothing seemed to help.
And why do xterms started before the modmap get the correct mods but not
the ones started after the modmap?
I'd appreciate any insights or pointers before I go snorking around in the
xterm sources. Thanks loads, in advance.
- Gary Oberbrunner
Thinking Machines Corporation
245 First St
Cambridge, MA 02142
garyo@think.com
p.s: is there any way to reset the default modmap if you've screwed it up
beyond recognition?rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (01/10/90)
p.s: is there any way to reset the default modmap if you've screwed it up
beyond recognition?
Log out. :-) There's no protocol request to do this.garyo@THINK.COM (Gary Oberbrunner) (01/10/90)
Bob, I just wanted to take a minute to let you know that you are positively amazing. I don't know anyone else who has your kind of detailed knowledge, is willing to take the time to respond to random losers' questions, and still make major contributions to products. I am really impressed. You must answer 10 or 20 questions a day, in addition to fielding others and getting real work done. That's no easy task even for a devoted customer-service type, much less someone for whom it's only a small part of the job. And you also have a sense of humor, and can resist flaming people, even when they are really asking for it. :-) Thanks for being there, Bob! You are a big part of what makes X so successful, and what makes all of us winners. Keep it up! - Gary Oberbrunner Thinking Machines Corporation 245 First St Cambridge, MA 02142 garyo@think.com
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (01/10/90)
The major symptom is that my shell (tcsh), which runs in cbreak mode and
eats 8-bit characters (hi bit == META), doesn't work properly with xmodmap
and xterm.
Interesting bug. I don't know exactly what's causing it yet, but a workaround
is to NOT put "Meta" keys on the "control" modifier. If I understand what you
want correctly, you're simply turning some additional keys into control keys;
if that's the case, also relabel those keys with a "Control" keysym; don't
retain the "Meta" keysym on those keys.garyo@THINK.COM (Gary Oberbrunner) (01/12/90)
I ask:
Why should I have to change the keysyms in my xmodmap just to change
the modifier bits associated with some keys?
Bob replies:
Because of the way "Meta" is defined. It isn't defined by "a key that
has Meta on it", it's defined by "a modifier bit that has an associated
key that has Meta on it". For better or worse (the Xt spec is probably
too liberal) the control modifier is included in this search, so it
gets treated as both control and meta simultaneously. At least I think
that's what's going on.
I know it's just me, but I still don't fully get it. The Xt doc on this
(finally found it!) says something like this:
Meta is defined by "ANY (???) modifier bit whose corresponding keycode
(what if there are >1?) contains the corresponding left or right keysym
(Meta_L or Meta_R, I guess)."
Isn't this extremely strange? Is my interpretation right? Was it really
like this in R3?
How does this work in practice (and where is it done in the source)?
And why is this in the Xt spec anyway? Shouldn't this all be in the red
book? I'd expect this stuff to be defined with XLookupString. No wonder I
couldn't find it!
Is this because I have two physical keys with the same keysym
(Control_L)?
Yes, xmodmap only adds the first key that it finds with the specified
keysym, not all keys. You should have figured this out from the
keycode values that xmodmap prints out (in parens). You'll have to
stand on your head a bit to fix this; xmodmap is stupid and only
accepts keysyms in the add command. You'll have to first label the key
with some unique keysym, then do the add, then change the keysym to
Control.
Clearly here you're saying that the keysym is not used to look up the
modifier bits at run time. This jibes with the Xt doc, which says that
Shift, Lock and Control are treated specially - they just look at the
modifier map, not the keysym. Why are they different?
- Gary Oberbrunner
Thinking Machines Corporation
245 First St
Cambridge, MA 02142
garyo@think.comrws@EXPO.LCS.MIT.EDU (Bob Scheifler) (01/12/90)
Meta is defined by "ANY (???) modifier bit whose corresponding keycode
(what if there are >1?) contains the corresponding left or right keysym
(Meta_L or Meta_R, I guess)."
"one of whose corresponding keycodes" might be better wording. You have
the idea.
Isn't this extremely strange?
Which part do you find strange?
Was it really like this in R3?
The specification was. Dunno for sure about the implementation.
(and where is it done in the source)?
You don't really want to know, but you can start in TMstate.c, e.g.
_XtBuildKeysymTables and ComputeLateBindings.
Shouldn't this all be in the red book?
No, this is a prescript, not a PostScript. :-)
It is possible that we would have been better of standardizing interpretations
in the protocol (maroon book), I don't know. The current (R4) protocol document
does have this to say:
Switching between groups is controlled by the KEYSYM named
MODE SWITCH, by attaching that KEYSYM to some KEYCODE and attaching that
KEYCODE to any one of the modifiers Mod1 through Mod5. This modifier is
called the ``group modifier''.
and
The KEYMASK modifier named Lock is intended to be mapped to either a CapsLock
or a ShiftLock key, but which one is left as application-specific
and/or user-specific.
However, it is suggested that the determination be made according to the
associated KEYSYM(s) of the corresponding KEYCODE.
so a mechanism for "defining" modifiers Mod1-Mod5 should be pretty clear.
I'd expect this stuff to be defined with XLookupString.
XLookupString is a convenience routine, dealing only with Shift, Lock,
Control, and the group modifier.
Clearly here you're saying that the keysym is not used to look up the
modifier bits at run time.
That's not really what I was saying, I was describing a defect in xmodmap
and how to work around it.
This jibes with the Xt doc, which says that
Shift, Lock and Control are treated specially - they just look at the
modifier map, not the keysym. Why are they different?
Because they are considered standard modifiers, that exist on virtually every
keyboard (or on every keyboard virtually), and should have a standard
interpretation. That's why they are "named" in the protocol, instead of being
"numbered".garyo@THINK.COM (Gary Oberbrunner) (01/13/90)
Date: Fri, 12 Jan 90 10:48:02 -0500
From: rws@expo.lcs.mit.edu (Bob Scheifler)
Meta is defined by "ANY (???) modifier bit whose corresponding
keycode (what if there are >1?) contains the corresponding left or
right keysym (Meta_L or Meta_R, I guess)."
"one of whose corresponding keycodes" might be better wording. You
have the idea.
Isn't this extremely strange?
Which part do you find strange?
The fact that the keysym instead of the modifier bit is the key
determiner of 'metification', and also the fact that any mod bit works, not
just mod1. I started out expecting that any keycode appearing in the mod1
modmap would be a meta key, independent of its keysym. Seems simple - the
server sees the key-down, it looks it up in the modmap, and sets any
key-event mod state bits that are mapped to that keycode. I'd expect ditto
for super, hyper, alt on mod2, mod3, mod4 (or whatever; the Xt doc is
unclear on how they map). And I expected that if you didn't want the key
to generate anything else other than setting a modifier state bit, you'd
set its keysym to some random "not used" code. This expectation is
probably an outgrowth of my gmacs background, where you define a key to be
a "prefix" key that sets mod bits rather than having any immediate effect.
But it appears that in fact to be a meta key (i.e. to set the mod1 state
bit in successive key events), a keycode must have either Meta_L or Meta_R
in its keysym list, *and* it must set a modifier bit (any mod bit). (Is
this right? Is it finally penetrating my thick skull? Why are control &
shift different?) That's what I find strange. It makes is more difficult
to have several meta (or control, or whatever) keys, and it seems to me
less conceptually clear.
Thanks again for clarifying this stuff.
- Gary Oberbrunner
Thinking Machines Corporation
245 First St
Cambridge, MA 02142
garyo@think.comrws@EXPO.LCS.MIT.EDU (Bob Scheifler) (01/13/90)
I started out expecting that any keycode appearing in the mod1
modmap would be a meta key, independent of its keysym.
Even though Mod1 is called Mod1, not Meta? Hmm, perhaps you're a carryover
from R2 (R1?) days, when it was hardwired this way.
I'd expect ditto
for super, hyper, alt on mod2, mod3, mod4 (or whatever; the Xt doc is
unclear on how they map).
They map the same way as Meta; they don't map to a specific modifier bit,
it's a dynamic assignment.
But it appears that in fact to be a meta key (i.e. to set the mod1 state
bit in successive key events), a keycode must have either Meta_L or Meta_R
in its keysym list, *and* it must set a modifier bit (any mod bit).
Close. You really mean "set a modifier state bit" and "set that modifier bit".
Why are control & shift different?
Because (as I said before) they are viewed as universal, they should always
exist on the keyboard. The others are dynamic because the set of modifiers
you want for a given set of applications may vary (there can be other modifiers
besides the standard ones).
It makes is more difficult
to have several meta (or control, or whatever) keys, and it seems to me
less conceptually clear.
Except for bogosity in xmodmap, I don't think it's any harder to have multiple
keys. Conceptually, you think of putting labels on all of their keycaps (that's
the keysyms). To simplify programmatic keyboard state management wrt focus
issues, these keys are tied to modifier bits. xmodmap probably ought to have
a better interface for describing this (e.g. "make this set of keys the Meta
modifier", which picks a modifier bit for you).