Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!hellgate.utah.edu!uplherc!esunix!bambam!bpendlet
From: bpendlet@bambam.UUCP (Bob Pendleton)
Newsgroups: comp.windows.x
Subject: Re: Inventing A Shift Key
Message-ID: <141@bambam.UUCP>
Date: 15 Sep 89 15:10:08 GMT
References: <8909112116.AA02930@devnull.sun.com>
Organization: Evans & Sutherland Computer Corp., Salt Lake City, Utah
Lines: 39

From article <8909112116.AA02930@devnull.sun.com>, by dshr@SUN.COM (David Rosenthal):
> The interpretation of keys is entirely up to the client.
> The Sun server is correctly reporting that:
> 
> -	There is a key marked "Num Lock"
> -	When pressed,  it goes down
> -	When released,  it comes up (i.e. it doesn't physically lock down)
> 
> Thus,  the clients find out what the actual state of the keyboard is.
> This is what the designers of the X protocol intended.  

Right.....

In the Sun keyboard handler in the Sun DDX when you press the caps
lock key a key pres event is prepared. Then a check is made to see if
the caps lock key is already "down". If it is already "down" the event
type is changed to KeyPress event and sent along. All KeyRelease
events actually generated by releasing the caps lock key are
supressed. 

In other words, the Sun DDX keyboard code "lies" about the state of
the caps lock key so that it will appear to be down even though it
CAN'T be locked down. 

So much for reflecting the actual state of the keyboard. The logical
state is a lot more useful. You could do the same thing for the num
lock key. You would have to figure out what to put in the ModMap for
the key. 

I don't know what you would have to do to the KeyMap to make it work
the way you want. I've RT'd every FM I have and now I'm UTSLing trying
to find out. 

			Bob P.
-- 
              Bob Pendleton, speaking only for myself.
UUCP Address:  decwrl!esunix!bpendlet or utah-cs!esunix!bpendlet

           Reality is stanger than most people can imagine