Path: utzoo!attcan!telly!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!mit-eddie!bloom-beacon!dont-send-mail-to-path-lines
From: mouse@lightning.mcrcim.mcgill.EDU
Newsgroups: comp.windows.x
Subject: Re:  K/B modifier to act as Lock key ?
Message-ID: <9102220816.AA00635@lightning.McRCIM.McGill.EDU>
Date: 22 Feb 91 08:16:45 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 46

> I am trying to figure out how to make a modifier key act as a switch
> key (ala Caps Lock), and not as a shift key (ala shift).

Sorry, no can do, as far as I can tell.  (Well, that's not quite true;
see later.)

As far as I can see, the protocol does not make any distinction between
lock-down keys and any other sort.  That is, from the point of view of
the protocol, CapsLock is just like any other key, except that it gets
held down for a lot longer than most.  On some keyboards, this is
implemented mechanically; on others, it's in the electronics but still
can't be changed, and on still others, it's done in the X server.  In
the MIT Xsun, for example, I find the following code:

    if (keyModifiers & LockMask) {
	if (xE.u.u.type == KeyRelease)
	    return; /* this assumes autorepeat is not desired */
	if (BitIsOn(((DeviceIntPtr)pKeyboard)->key->down, key))
	    xE.u.u.type = KeyRelease;
    }

In other words, when a key that's tied to the Lock modifier changes
state, the server discards all release events and changes every second
press event into a release event.  (This happens very early, before the
event gets out of the device-dependent portion of the server.)

Other servers may have other hacks; for example, some might decide
whether a key should lock based on its keycode instead of what keysym
or modifier it's been tied to.  From your description of your
experiments, I'd guess that either your server is doing this or your
keyboard is doing the locking in hardware.

IMO this situation is dreadful.  I would like to see one bit per key
specifying whether the key "locks" or not, with requests to set and
clear these bits.  (Servers forced to deal with keys that lock in
hardware, either mechanically or electronically, perhaps couldn't
implement this - maybe it could be an extension.)

That said, you *can* sort-of do this.  It would be a major kludge and
would probably slaughter performance, but I *think* you can do
something with grabs and XAllowEvents(...,ReplayKeyboard,...).

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu