thsrem@tumuc.UUCP (Thomas Schneider) (02/11/89)
Hi, I am working on an server implementation for Nixdorf.
I would like to ask the net the following questions:
1. Why are the keycodes restricted to [8,255] ?
Do the reserved 8 codes correspond to the 8 possible modifiers ? Why? How?
(It seems there is a typo in O'Reilly's Xlib Program. Manual Page 250:
"The keycode ... is a number between 7 and 255").
I have keys which generate 1 and 5. I need to map them into [8,255], right?
2. (more difficult)
My Nixdorf keyboard has 3 engravings on some keys.
The third engravings ought to be addressed with a separate "modifier".
The hard thing is that some ASCII symbols (as [, ], {, }, |, etc.)
can only be accessed by this "modifier".
My first approach was to change the server code to let the table
which maps from keycodes to keysyms have a third column for this "modifier".
BUT: xterm doesn't look at this column at all.
Thus I am not able to type a "|" in xterm.
I could change Xlib to handle this but a SUN xterm connected to my
machine would still be broken.
The only (ugly) solution I can think of:
Make an additional mapping before any other mapping from
let's say "physical" keycodes to "virtual" keycodes
which would map the code for "|" to a separate "virtual" keycode.
My special "modifier" would by hidden to any client
and the clients would "see" additional keys for [, ], | etc.
Am I missing something?
Is there any other way to do it?
3. I learned that the keycode/keysym mapping is server wide.
Why is this mapping handled on the client side
with all the toubles of SHIFT, LOCK, CONTROL and updating?
Why does the protocol not just handle keysyms?
Sorry for the long questions. I tried to be as short and clear as possible.
Thomas Schneider.
UUCP: uunet!unido!tumuc!thsremdshr@SUN.COM (David Rosenthal) (02/12/89)
"Don't, don't believe, don't believe the hype." Public Enemy "It takes a nation of millions to hold us back" As I keep having to say these days, X does not guarantee portability. Keyboard handling is yet another area where portability is not guaranteed; read the section of the spec. about Keysym Encoding for some of the arguments in this area. Further, there is a comment in the file lib/X/XKeyBind.c: /* Beware, here be monsters (still under construction... - JG */ This isn't just an accidental left-over from the alpha and beta days, it is still true. The whole question of conversion from keycodes to strings in a suitable
dshr@SUN.COM (David Rosenthal) (02/13/89)
"Don't, don't believe, don't believe the hype." Public Enemy "It takes a nation of millions to hold us back" As I keep having to say these days, X does not guarantee portability. Keyboard handling is yet another area where portability is not guaranteed; read the section of the spec. about Keysym Encoding for some of the arguments in this area. Further, there is a comment in the file lib/X/XKeyBind.c: /* Beware, here be monsters (still under construction... - JG */ This isn't just an accidental left-over from the alpha and beta days, it is still true. The whole question of conversion from keycodes to strings in a suitable text encoding (including ASCII) is still up in the air. To address your questions: > 1. Why are the keycodes restricted to [8,255] ? To ensure that the KeymapNotify event fits in an event (32 bytes). > Do the reserved 8 codes correspond to the 8 possible modifiers ? Why? How? No relationship. > (It seems there is a typo in O'Reilly's Xlib Program. Manual Page 250: > "The keycode ... is a number between 7 and 255"). That's a typo. > I have keys which generate 1 and 5. I need to map them into [8,255], right? Correct. See the Sun code for a similar case. > 2. (more difficult) > My Nixdorf keyboard has 3 engravings on some keys. > The third engravings ought to be addressed with a separate "modifier". Correct. Presumably there is some keycode that acts as a modifier to get these. Your server should start up with this key defined as a modifier (say MOD1). > The hard thing is that some ASCII symbols (as [, ], {, }, |, etc.) > can only be accessed by this "modifier". I infer, though you don't say, that the problem is that the keys with these keysyms on have 3 keysyms all of them representing ASCII characters. > My first approach was to change the server code to let the table > which maps from keycodes to keysyms have a third column for this "modifier". Correct. This table needs to be wide enough to accomodate all the KEYSYMS on any keycap. > BUT: xterm doesn't look at this column at all. > Thus I am not able to type a "|" in xterm. > I could change Xlib to handle this but a SUN xterm connected to my > machine would still be broken. The problem here is not xterm. It is the Xlib routine XLookupString(). There is no way that it can guarantee to understand ALL possible keyboards and what they mean in terms of ASCII (let alone all possible text encodings). Despite the caveat above, XLookupString() is broken. In the initialization, XLookupString should take a resource that specifies a set of key+modifier pairs (specified as a base keysym and a modifier keysym, not as codes) that override the default built-in interpretation. At present, XLookupString() has a built-in key+modifier mapping that uses only the Shift and Lock modifiers. The right way to add to this is by using resources, not by wiring more individual cases into Xlib. In fact, the default key+modifier mapping should probably be removed from the Xlib code to a resource. The user, not the server or Xlib, is the one that really knows what the keyboard looks like - I know of no way for the hardware to know what is written on the little paper stickers covering the keys on my keyboard. A group of people probably need to get together to deal with the inadequate state of XLookupString(). Maybe some such activity is underway in the Consortium - I don't know. > The only (ugly) solution I can think of: > Make an additional mapping before any other mapping from > let's say "physical" keycodes to "virtual" keycodes > which would map the code for "|" to a separate "virtual" keycode. > My special "modifier" would by hidden to any client > and the clients would "see" additional keys for [, ], | etc. That would work, but it's really ugly. > Am I missing something? > Is there any other way to do it? There's really no good way to do what you want to do without fixing the /* Beware, here be monsters (still under construction... - JG */ problem. > 3. I learned that the keycode/keysym mapping is server wide. > Why is this mapping handled on the client side > with all the toubles of SHIFT, LOCK, CONTROL and updating? > Why does the protocol not just handle keysyms? Because we need to be able to support clients that want to deal with the keyboard as a raw device, not as an encoded device. For example, building an application that displays the state of the keyboard, with the keys labelled. And for data compression - the keycode is an index into a table. David.