benson@odi.com (Benson I. Margulies) (09/12/89)
This message is looking for an answer from one of the designers of the dix / ddx stuff, or someone who knows a lot about it. Sun's latest keyboard has a key marked "Num Lock." as far as I know, there is no kernel support for treating it as a shift lock key. I have been stumped trying to see if the X11R3 server code already includes some generic support for defining a key that locks some number of keycodes into their shifted keysym. For example, would I need a third column in the mapping table? And how would I specify that num-lock shoved things into the third column? thanks in advance. benson -- Benson I. Margulies
dshr@SUN.COM (David Rosenthal) (09/12/89)
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. How clients interpret this information is up to them. For example, if they decide to let down (or up) transitions of this key toggle their interpretation of other key events between a normal and a "Num Lock" interpretation, that is up to them. To sum up, the way to change the way keys are interpreted is to change the clients. Persuading the server to lie to its clients about the state of the keyboard is a very bad idea. David.
barmar@think.COM (Barry Margolin) (09/12/89)
In article <8909112116.AA02930@devnull.sun.com> dshr@SUN.COM (David Rosenthal) writes: >The interpretation of keys is entirely up to the client. That's not entirely true. I believe Benson can do what he wants using xmodmap (I don't remember the names of the analogous xlib calls, but they are reasonably well documented). Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
benson@odi.COM (Benson I. Margulies) (09/12/89)
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. How clients
interpret this information is up to them. For example, if they
decide to let down (or up) transitions of this key toggle their
interpretation of other key events between a normal and a "Num Lock"
interpretation, that is up to them.
To sum up, the way to change the way keys are interpreted is to change
the clients. Persuading the server to lie to its clients about the
state of the keyboard is a very bad idea.
David.
So you would put code into every single client to individually
interpret Num Lock? Doesen't that leave something to be desired in terms
of modularity?
Well, what if the manufacturer of this workstation didn't build the
shift lock key into the hardware or the kernel in a useful manner.
Surely, then, one would want the server to simulate it. Or would you prefer
each client to independently invent shift lock just in case some workstations
didn't maintain state in the hardware or kernel.
The standard keysym inventory includes the KP keysyms, just as it
includes both "a" and "A". If a piece of hardware had a key marked
"Shift" that just sent a keycode, surely one would diddle the server
to remember state and shift a to A. So I suggest that the standard
interpretation of NumLock should be to shift into the KP symbols.rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (09/12/89)
So you would put code into every single client to individually
interpret Num Lock?
Yes.
If a piece of hardware had a key marked
"Shift" that just sent a keycode, surely one would diddle the server
to remember state and shift a to A.
No. Interpretation of Shift and Lock (and Control and ...) is already done
on the client side, not in the server. Num Lock should be no different in
this respect.
You might well argue that Xlib's XLookupString should have support for NumLock
in it, and you'll find people to agree with you. There are other things that
people claim XLookupString should also handle, like Compose processing and
complex input methods (e.g. Kana-Kanji conversion). All of this is currently a
discussion topic within the X Consortium.dshr@SUN.COM (David Rosenthal) (09/12/89)
> So you would put code into every single client to individually > interpret Num Lock? Doesen't that leave something to be desired in terms > of modularity? > The goal is not modularity (though for any system that supports shared libraries, there cost is insignificant). The goal is flexibility. The goal is to allow clients that deal with the keyboard in different ways (for example, Japanese and Spanish) to co-exist. Or for a single client to be able to deal with the keyboard as required for Korean and Urdu. > Well, what if the manufacturer of this workstation didn't build the > shift lock key into the hardware or the kernel in a useful manner. > Surely, then, one would want the server to simulate it. Or would you prefer > each client to independently invent shift lock just in case some workstations > didn't maintain state in the hardware or kernel. > There is no need to build code into the kernel or the server to imitate a locking shift key if no such key exists. "Just the facts, mam" is all that X needs. > The standard keysym inventory includes the KP keysyms, just as it > includes both "a" and "A". If a piece of hardware had a key marked > "Shift" that just sent a keycode, surely one would diddle the server > to remember state and shift a to A. So I suggest that the standard > interpretation of NumLock should be to shift into the KP symbols. > You clearly don't understand the first thing about how keyboard support works in X, or you would not have made this suggestion. Please study pages 352-353 and 506-509 of the Digital Press book before continuing this conversation. David.
benson@odi.COM (Benson I. Margulies) (09/13/89)
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.
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (09/13/89)
Is there some client subroutine in Xlib that is conventionally called that
is really running the show?
For many clients, yes, it's XLookupString.
"Could num-lock have a conventional interpretation like shift-lock?"
It could possibly, but it doesn't today (in Xlib or Xt).bpendlet@bambam.UUCP (Bob Pendleton) (09/15/89)
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
guy@auspex.auspex.com (Guy Harris) (09/19/89)
>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. The DEC LK201 code in the MIT server appears to do the same thing, BTW.