devil@techunix.BITNET (Gil Tene) (02/20/91)
Hello XFolk ! 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). I just found out about the Mode_switch Keysym in R4, it is GREAT! It let's me map an alternate keyboard very easily, and doesn't really affect the "main" keyboard mapping. There is only one thing wrong: it seems I can only use it as a "shift-like" modifier, and not "caps-lock-like" : e.g. : I can't seem to find a way to cause the key mapped to Mode_switch to act as a switch (on/off), instead of a hold-it-down-to-use key. Experimenting under OpenWindows 2, I found that I must map Mode_switch as modifier mod3, otherwise it won't work. I also found that num-lock must be mapped as mod4. When I switch the Num_Lock and Mode_switch modifier settings (mod3 = Num_Lock, mod4 = Mode_switch) The Num_Lock key acts as a Mode_switch key (just what I wanted, a switch mode Mode_switch key), and the Mode_switch key (Alt Graph on the KB) acts like a Num_Lock, only it doesn't lock, and must be used as a shift key. What I want to do is define Mode_switch to act as a lock key, without hurting my Num_lock definitions. Does anyone out there know how to do this ? AdvThanks, -- Gil. -- -------------------------------------------------------------------- | Gil Tene "Some days it just doesn't pay | | devil@techunix.technion.ac.il to go to sleep in the morning." | --------------------------------------------------------------------
mouse@lightning.mcrcim.mcgill.EDU (02/22/91)
> 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