tek@penzance.cs.ucla.edu (02/15/91)
Why does the R13 key (keycode 119) in the MIT Xsun server have the
keysym R13?
This might seem like a strange question, except that all the other
special function keys on the keyboard (like L5, F2 and R6) all have
"Fx" keysyms (where x is from 1 to 35). Some may have other keysyms
like "Up". In any case, it seems the natural progression would assign
"F33" to keycode 119.
Have I missed something here?
Am I the only one with a twisted keyboard map?
-ted
Ted Kim Internet: tek@penzance.cs.ucla.edu
UCLA Computer Science Department UUCP: ...!{uunet|ucbvax}!cs.ucla.edu!tek
3804C Boelter Hall Phone: (213)206-8696
Los Angeles, CA 90024 FAX: (213)825-2273mouse@lightning.mcrcim.mcgill.EDU (02/16/91)
> Why does the R13 key (keycode 119) in the MIT Xsun server have the > keysym R13? > This might seem like a strange question, Yes; it almost begs to be answered "Maybe because it's the R13 key!" :-) It's also not unique to Suns. I would expect any server with an R13 key to have the same "problem". > except that all the other special function keys on the keyboard (like > L5, F2 and R6) all have "Fx" keysyms (where x is from 1 to 35). In > any case, it seems the natural progression would assign "F33" to > keycode 119. First, note that R13 and F33 are actually the same keysym; they both turn into the same keysym code. The only mystery is why you get "R13" rather than "F33" when you translate keysym 0xffde back into a name. Here is a snippet of keysymdef.h from our system: #define XK_F27 0xFFD8 #define XK_R7 0xFFD8 #define XK_F28 0xFFD9 #define XK_R8 0xFFD9 #define XK_F29 0xFFDA #define XK_R9 0xFFDA #define XK_F30 0xFFDB #define XK_R10 0xFFDB #define XK_F31 0xFFDC #define XK_R11 0xFFDC #define XK_F32 0xFFDD #define XK_R12 0xFFDD #define XK_R13 0xFFDE #define XK_F33 0xFFDE #define XK_F34 0xFFDF #define XK_R14 0xFFDF #define XK_F35 0xFFE0 #define XK_R15 0xFFE0 Notice that in most cases, the F keysym is listed first, but in the case of F33/R13, the R keysym is listed first. UTSLing reveals that xmodmap simply uses XKeysymToString, and that XKeysymToString gets its list from ks_names.h in mit/lib/X. This file begins with a comment /* * This file is generated from $(INCLUDESRC)/keysymdef.h. Do not edit. */ which indicates that keysymdef.h is the primal source, but I have been unable to locate anything which rebuilds ks_names.h if you modify keysymdef.h. In any case, it's clear what's up: XKeysymToString is finding R13 because that's the first name given for 0xffde. I have no idea *why* R13 and F33 are switched. I agree it doesn't really make sense. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu