[11128] in Athena Bugs
sun4 7.6L: Capslock vs. xmodmap
daemon@ATHENA.MIT.EDU (cfields@MIT.EDU)
Fri Oct 1 18:17:18 1993
From: cfields@MIT.EDU
Date: Fri, 1 Oct 93 18:17:03 -0400
To: kdo@MIT.EDU, rptaurie@MIT.EDU, bugs@MIT.EDU
Cc:
kdo writes:
> What should have happened:
> Only when a key is set to the "lock" modifier should it be push-on
> push-off.
Yes, you are correct. In addition, it should be the case that ``When a
key is set to the "lock" modifier, it should be push-on push-off.''
Unfortunately, this is also false. Only a key with the "Caps_Lock"
keysym associated can properly act as the caps lock key.
rptaurie writes:
> I use this to change the capslock key to control, and it works fine
> (don't ask me to explain it, it's the result of trial and error):
> remove Lock = Caps_Lock
> keycode 126 = Control_L
> add Control = Control_L
I would advise giving the Caps_Lock key its own keysym, rather than
having it share with another key. For instance,
remove Lock = Caps_Lock
keycode 126 = Super_L
add Control = Super_L
(or add mod1 = Super_L)
kdo writes:
> That works, thanks. God, xmodmap is a crock.
Actually, xmodmap is fine; it is Sun's X server that is losing.
> Each actual key (i.e. keycode) can have a keysym (something like
> Meta_L or X) associated with it. In addition, the key can have a
> modifier effect white it is held down.
True.
> Keysyms like Meta_L don't send anything when you push them,
They do actually, depending what you mean by "send." The X server
sends the keypresses of modifiers to clients just like it would
any other keypresses. However, clients usually ignore them.
> so if a key is mapped to Meta_L then it does nothing except as a
> modifier. Xmodmap's language doesn't fit this model,
I don't know why you say the language doesn't fit.
> so that the command "add mod1 = Meta_L" means find all actual keys
> that are set to the (no-op) Meta_L keysym and add those keys to the
> modifier list for mod1.
> The xmodmap program seems to control the latching behavior of the Sun
> caps lock key as follows: If you add a modifier to this key while the
> key is set to the Caps_Lock keycode, then the latching feature is
> enabled, and if you add a modifier to the key while the key is set to
> some other keycode then latching is disabled.
Actually, xmodmap doesn't have anything to do with it. It's only
manipulating symbols and passing information to the X server. It's the
X server that's messed up. It treats keys with the "Caps_Lock" keysym
associated with them as locking keys, in order to provide the correct
caps lock functionality. This is the wrong solution (as well as a gross
hack), as it causes the problems you are reporting. I don't know why Sun
did it this way. Other implementations treat keys associated with the
"lock" modifier as locking, and this is the right solution.
We'll pass this bug along to Sun...
Craig
