Path: utzoo!attcan!uunet!ginosko!ctrsol!cica!iuvax!purdue!gatech!bloom-beacon!odi.COM!benson
From: benson@odi.COM (Benson I. Margulies)
Newsgroups: comp.windows.x
Subject: Re: Inventing A Shift Key
Message-ID: <8909121713.AA01678@cass.odi.com>
Date: 12 Sep 89 17:13:20 GMT
References: <8909121622.AA03377@devnull.sun.com>
Organization: The Internet
Lines: 35


I read the indicated pages, and I read their earlier form long ago.
I am greatly confused about your notion of "what the keyboard does."
The physical object sitting in front of me just sends codes to its system.
ShiftLock is just another key. The kernel keyboard driver, on request,
makes Shift and ShiftLock do what you expect.  The server configures
it in that mode of operation. So the notion of "just the facts" confuses
me no end. "sticky" or even "shift" keys are a software construct
on this and some other workstations.

I think that the root of my confusion is my failure to figure out
how the modifier keys work. 
The shift modifier is defined in the keyboard map as just another keycode.
Is the server observing keypress for Shift and then setting internal state
that changes its interpretation of "a"? 
Or is the binary code coming from the kernel for Shift-A composed of
the code for a orred in with a code for Shift? And if the later,
what piece of code performs that decoding? Looking at xev, I see a 
"state" variable that reflects the collection of modifiers that are
down. So I suspect, though I don't know, that the definition of Shift_L
as the Shift modifier causes the low bit of the state to reflect
the state of that key.  On page 352, what piece of code is supposed
be performing the various actions related to Lock that are described?
The platform specific portion of the server? The clients? Is there
some client subroutine in Xlib that is conventionally called that
is really running the show?

If I were a vendor, it seems to me that its my business whether I implement
the shift lock key as a physical switch in the keyboard, as a stateful
bit of the kernel driver, or as a stateful bit of the X server. 

Which sort-of brings me back to NumLock. My original question (in my own
mind, at least) was this: "Could num-lock have a conventional interpretation
like shift-lock?" Such an interpretation might be reflected as comments
like those on page 352.