[11051] in Athena Bugs

home help back first fref pref prev next nref lref last post

Re: sun4 7.6L: Capslock vs. xmodmap

daemon@ATHENA.MIT.EDU (Ken Olum)
Thu Sep 23 17:27:46 1993

Date: Thu, 23 Sep 1993 15:38:49 -0400
From: kdo@marie.mit.edu (Ken Olum)
To: rptaurie@MIT.EDU
Cc: bugs@MIT.EDU
In-Reply-To: <9309231905.AA15816@w20-575-116.MIT.EDU> (rptaurie@MIT.EDU)

That works, thanks.  God, xmodmap is a crock.  Here's my
interpretation of what must be happening:

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.  Keysyms like Meta_L don't send
anything when you push 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, 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.

So the important thing is to first get some other keycode associated
with this key (it doesn't matter which one, except that you don't want
to affect other keys randomly), and then add it to the mod1 modifier.

Sigh.

						Ken

home help back first fref pref prev next nref lref last post