mikep@sco.COM (Mike Patnode) (01/07/91)
The following is a proposal for new keysyms to be added to the Standard
X Keysym definition. Please send me any comments you may have. This
will be brought up for discussion at the i386 X Developer's BOF being
held on Tuesday night at the MIT Technical Conference.
See you there.
mp
-----
Mike Patnode The Santa Cruz Operation
Software Engineer 400 Encinal Street
{ucscc,uunet}!sco!mikep mikep@sco.COM P.O. Box 1900
(408) 458-1422 Santa Cruz, CA 95061
--------------------- cut here -----------------------
Title : PC/AT Keyboard X Keysym Proposal
Date : Thu Jan 05 1991
Status : DRAFT - for comments
Synopsis : This document describes a proposal for
new X keysyms to be added to the X11
KEYSYM Standard Encoding. Because of
the large number of PC/AT keyboards in
use, and the number of different
companies producing X servers for
machines with these keyboards, vendor
specific keysyms are not an appropriate
solution. Futhermore, a complete set of
standard keysyms for the PC/AT keyboard
will be needed to aid portability in
application binaries which comply with
the Intel386 Binary Compatibility
Specification. This document proposes
13 new keysyms in all: one for which
there was no X equivalent, the others
in order to uniquely identify the
cursor and page control glyphs which
share the numeric keypad.
Author :
Mike Patnode
The Santa Cruz Operation
mikep@sco.com
Distribution :
comp.windows.x
jimg@sco.com
jsw@sgi.com
kylec@sco.com
mikep@sco.com
rws@expo.lcs.mit.edu
scottw@ico.isc.com
(c) 1991 The Santa Cruz Operation, Inc.
- 2 -
1. Introduction
Since the majority of X Window research and development has
been historically done on UNIX workstations there was never
a great deal of emphasis put upon Intel based personal
computers. Now, with the emergence of faster Intel 386 and
486 based machines, the PC/AT computer has become a viable
UNIX workstation. There are a number of software vendors
who produce X servers for these machines, as well as some
non-Intel hardware manufactures who have adopted the IBM AT
keyboard layout. Unfortunately, the standard X Keysyms are
not sufficient to represent all the keys on the IBM AT and
PC keyboards.
2. Keypad Glyphs
The main problem arises from the PC/AT numeric keypad. The
numeric glyphs share a key with the cursor and page control
keys. The X Keysym definition provides special keysyms for
most keypad keys which may also be present elsewhere on the
keyboard. It does not provide keypad keysyms for the arrow
or page controls keys. Hence, on the IBM AT keyboard, an X
programmer cannot easily distinguish between the Up Arrow
key and the Keypad Up Arrow key unless the server writter
provides non-standard or unintuitive keysym names.
The simple solution is to create new standard keysyms for
the PC/AT keyboards. Not only are these keyboards in wide
spread use, but this will also aid X application programmers
who are trying to comply with the Intel386 BCS.
This introduction of new keysyms may cause some problems
with existing applications, but it is hoped that most X
programs should be able to overcome these incompatibilities
via the translation table mechanism.
(c) 1991 The Santa Cruz Operation, Inc.
- 1 -
3. New Keysyms
There are 3 main areas which this proposal covers. One is
simply a common key for which there is no keysym equivalent
defined. The second is the 11 keypad keys which have two
glyphs each on the PC and AT keypad. Finally, there is no
Page Up or Page Down keysym defined. The keycodes (hex
values) used here are unused in the current keysym
definition. These values are only suggestions and are not a
requirement of the proposal.
There seems to be no X keysym which matches the SysReq key.
0xFF15 XK_Sys_Req System Request
Next is the PC/AT keypad. The current X keysym set already
defines some keypad keys such as KP_Enter and KP_Add. The
following keysyms are needed to complete the definition.
0xFF96 XK_KP_Home Keypad Home
0xFF97 XK_KP_Left Keypad Left Arrow
0xFF98 XK_KP_Up Keypad Up Arrow
0xFF99 XK_KP_Right Keypad Right Arrow
0xFF9A XK_KP_Down Keypad Down Arrow
0xFF9B XK_KP_Pg_Up Keypad Page Up
0xFF9C XK_KP_Pg_Dn Keypad Page Down
0xFF9D XK_KP_End Keypad End
0xFF9E XK_KP_Insert Keypad Insert
0xFF9F XK_KP_Delete Keypad Delete
The PC/AT Keyboard does not have a unshifted glyph on the
center keypad key (numeric 5). For the sake of consistency
the existing KP_Space keysym should be used here.
The last addition would be the regular Page Up and Page Down
keysyms. Although the X Keysym common approach would
suggest the use of Prior and Next, the large number of PC/AT
keyboards in use should justify the addition. Furthermore,
it would be more consistent with the new keypad keysym
definitions as well as the actual key engravings.
0xFF59 XK_Page_Up Page Up
0xFF5A XK_Page_Down Page Down
(c) 1991 The Santa Cruz Operation, Inc.
- 2 -
4. Conclusion
The goal of these additional keysyms is to allow a
application programmer to easily distinguish all of the keys
on the keyboard. Currently, this is a very difficult and
confusing process which is implemented differently by each
server. By introducing these keysyms as a standard for the
PC/AT keyboard, applications can be more easily written for
a variety of X platforms.
(c) 1991 The Santa Cruz Operation, Inc.erc@pai.UUCP (Eric F. Johnson) (01/08/91)
Regarding PC Keyboard Keysyms: Subject: PC/AT Keyboard X Keysym Proposal - R.F.C. Message-ID: <9452@scolex.sco.COM> Date: 7 Jan 91 00:52:24 GMT Organization: The Santa Cruz Operation, Inc. > The following is a proposal for new keysyms to be added to the Standard > X Keysym definition. Please send me any comments you may have. This > will be brought up for discussion at the i386 X Developer's BOF being > held on Tuesday night at the MIT Technical Conference. > mp ----- > Mike Patnode The Santa Cruz Operation > Software Engineer 400 Encinal Street > {ucscc,uunet}!sco!mikep mikep@sco.COM P.O. Box 1900 > (408) 458-1422 Santa Cruz, CA 95061 [..much deleted...Note that the indented material is Mike's, the flush-left stuff is mine.] Because of the large number of PC/AT keyboards in use, and the number of different companies producing X servers for machines with these keyboards, vendor specific keysyms are not an appropriate solution. Futhermore, a complete set of standard keysyms for the PC/AT keyboard will be needed to aid portability in application binaries which comply with the Intel386 Binary Compatibility Specification. This is a good reason to try to standardize things, but I think some of your ideas are just as bad as "vendor specific keysyms". Have you ever tried to run a program under SCO's OpenDesktop and display it on an X terminal or perhaps a Sun SPARCStation? Or tried to run a program on a Data General Aviion and display it on a PC running SCO's OpenDesktop? The whole idea should be to enhance interoperability with other systems, not detract from it. Your proposal makes this more difficult. 1. Introduction Since the majority of X Window research and development has been historically done on UNIX workstations there was never a great deal of emphasis put upon Intel based personal computers. Now, with the emergence of faster Intel 386 and 486 based machines, the PC/AT computer has become a viable UNIX workstation. There are a number of software vendors who produce X servers for these machines, as well as some non-Intel hardware manufactures who have adopted the IBM AT keyboard layout. Unfortunately, the standard X Keysyms are not sufficient to represent all the keys on the IBM AT and PC keyboards. But the standard X keysyms do come very close. Use the existing standard as much as possible before you design a new standard, OK? 2. Keypad Glyphs The main problem arises from the PC/AT numeric keypad. The numeric glyphs share a key with the cursor and page control keys. NOT necessarily. Some PC keyboards have a numeric keypad SEPARATE from the page/arrow keypad. On the PCs that share a numeric/page control keypad, there is the concept (borrowed from DOS) of a Num Lock key. The Num Lock key maintains a state, much like the more common Caps Lock. If the Num Lock is in the active state, then the shared keypad keys act as the numeric keys. In addition, the Num Lock light goes on to indicate to the user that the Num Lock state is active. If the Num Lock is in the inactive state, the shared keypad keys act as page and arrow controls, such as Page Up (or X11 XK_Prior). The problem is that few, if any, X servers support the Num Lock functionality. (It actually doesn't have to be in the server to work, as it could be in the Xlib, in routines used under the hood by XLookupString, et al. The key concept here is to make your PC-based X systems look more like a standard X system rather than less.) The X Keysym definition provides special keysyms for most keypad keys which may also be present elsewhere on the keyboard. I don't like those either, but if you've ever used VMS applications, you'll see some rational for making the keypad keysyms separate. (I still think a "1" is a "1" is a "1", to paraphrase Gertrude Stein.) It does not provide keypad keysyms for the arrow or page controls keys. Hence, on the IBM AT keyboard, an X programmer cannot easily distinguish between the Up Arrow key and the Keypad Up Arrow key unless the server writter provides non-standard or unintuitive keysym names. The simple solution is to create new standard keysyms for the PC/AT keyboards. Not only are these keyboards in wide spread use, but this will also aid X application programmers who are trying to comply with the Intel386 BCS. Argh. This will also make coding for multiple (e.g., PC and NON-PC) systems FUBAR. One of the major benefits of X is portability. With your proposal, we'd all have to add special-case code for PC-based systems. Your solution may be simpler for you personally, but remember there are a LOT of software developers out there, and I'm sure SCO would like more and more to port their software to SCO's X system. (And I hope the Intel386 BCS doesn't mandate your proposal.) This introduction of new keysyms may cause some problems with existing applications, but it is hoped that most X programs should be able to overcome these incompatibilities via the translation table mechanism. Give me a break. (If you require every X user to learn the translation table mechanism, you're severely limiting the potential number of X users.) 3. New Keysyms Finally, there is no Page Up or Page Down keysym defined. Yech-o. Use XK_Prior and XK_Next. There seems to be no X keysym which matches the SysReq key. 0xFF15 XK_Sys_Req System Request This is a good idea. Next is the PC/AT keypad. The current X keysym set already defines some keypad keys such as KP_Enter and KP_Add. The following keysyms are needed to complete the definition. 0xFF96 XK_KP_Home Keypad Home 0xFF97 XK_KP_Left Keypad Left Arrow 0xFF98 XK_KP_Up Keypad Up Arrow 0xFF99 XK_KP_Right Keypad Right Arrow 0xFF9A XK_KP_Down Keypad Down Arrow 0xFF9B XK_KP_Pg_Up Keypad Page Up 0xFF9C XK_KP_Pg_Dn Keypad Page Down 0xFF9D XK_KP_End Keypad End 0xFF9E XK_KP_Insert Keypad Insert 0xFF9F XK_KP_Delete Keypad Delete Double Yech-o. How about XK_Up and its kin? Or, in your order: XK_Home XK_Left XK_Up XK_Right XK_Down XK_Prior XK_Next XK_End XK_Insert XK_Delete The PC/AT Keyboard does not have a unshifted glyph on the center keypad key (numeric 5). For the sake of consistency the existing KP_Space keysym should be used here. Why not use XK_VoidSymbol, since the keypad 5 in page control mode does nothing on DOS machines anyway? Inserting a space char may confuse users. The last addition would be the regular Page Up and Page Down keysyms. Although the X Keysym common approach would suggest the use of Prior and Next, the large number of PC/AT keyboards in use should justify the addition. 0xFF59 XK_Page_Up Page Up 0xFF5A XK_Page_Down Page Down How does this justify it? If you really want to, define XK_PageUp and XK_PageDown to have the same value as XK_Prior and XK_Next. How may page up keysyms do you need? 4. Conclusion The goal of these additional keysyms is to allow a application programmer to easily distinguish all of the keys on the keyboard. Good goal, but why does it have to make coding portable applications harder? It doesn't have to. Currently, this is a very difficult and confusing process which is implemented differently by each server. By introducing these keysyms as a standard for the PC/AT keyboard, applications can be more easily written for a variety of X platforms. By the way, Mike's proposal is: (c) 1991 The Santa Cruz Operation, Inc. Mike, in my X applications, the concept of the Caps Lock key is essentially transparent. That is, when the Caps Lock is in the active state, my applications see "A" rather than "a" (or XK_A rather than XK_a). This means that my code doesn't have to program special cases for the Caps Lock key. This makes my job easier than it would have to be otherwise. Now, why can't the Num Lock key work much the same way? In other words, why can't your proposal make the Num Lock function essentially transparent to my application, e.g., through XLookupString() and the associated functions? If my code sees an XK_Up, it will know that an Up Arrow key was pressed, whether my code is running on an X terminal, a non-PC workstation or a PC-based workstation? If my code sees XK_Insert, it will know the Insert key was hit (except for an HP, but that's another matter). Millions of DOS users seem to handle the Num Lock concept just fine. Why not use that for PC-based UNIX systems as well? (An added benefit is that this will make it easier for DOS users to migrate to UNIX, and I suspect that a large number of SCO customers are migrating from DOS to UNIX, so you want to encourage this.) Making the Num Lock function transparently for applications may involve a bit of work on your part, but it will translate to a lot less hassle on the part of most software developers, and will fit in more with the spirit of following the X standard. You see, I have applications that need to run on a variety of UNIX workstations (including SCO's OpenDesktop) and be displayed on an even greater variety of workstations and X terminals. Every bit of special case code is a big pain, and there's already too much. With your proposal, not only will I have to have vendor-specific special case code (try to press XK_Insert on an HP for example, and you'll find XK_InsertLine or XK_InsertChar instead). I applaud your efforts at trying to standardize the use of PC keyboards. I like that. But, please, take another look at your proposal and try to make things easier for X application developers. Try to make your proposal fit in more with the X standard as it already exists. Please don't take this personally. It just seems that using the Num Lock key the way it was designed (for better or worse) is a LOT easier than adding in new arrow keys when we already have arrow keys. Good luck, -Eric PS. Data General also uses a PC keyboard on its Aviion series (which is based on the MC 88000, rather than the Intel processor family). They could use a bit of standardization in this regard as well. You might want to try to talk some DG folks into attending your BOF. -- Eric F. Johnson phone: +1 612 894 0313 BTI: Industrial Boulware Technologies, Inc. fax: +1 612 894 0316 automation systems 415 W. Travelers Trail email: erc@pai.mn.org and services Burnsville, MN 55337 USA
mikep@sco.COM (Mike Patnode) (01/10/91)
X i386 Developer's BOF note:
The BOF will still be held Tuesday night but will be scheduled to
not conflict with the X Security BOF. Hopefully it will immediatly
follow the Security BOFF in the same room. Please check the Notes
Board at the conference for details.
In article <1607@pai.UUCP> erc@pai.UUCP (Eric F. Johnson) writes:
>Regarding PC Keyboard Keysyms:
>
Much more deleted as I get to the meat and potatoes of Eric's
reasoning.
>
> The X Keysym definition provides special keysyms for
> most keypad keys which may also be present elsewhere on the
> keyboard.
>
>I don't like those either, but if you've ever used VMS applications,
>you'll see some rational for making the keypad keysyms separate. (I
>still think a "1" is a "1" is a "1", to paraphrase Gertrude Stein.)
What about XK_Alt_L and XK_Alt_R? XK_Enter and XK_KP_Enter?
>Argh. This will also make coding for multiple (e.g., PC and NON-PC)
>systems FUBAR. One of the major benefits of X is portability.
>With your proposal, we'd all have to add special-case code for
>PC-based systems.
Why special-case code? If you did not want to differentiate the two
arrow keys your code, but you wanted to run on a PC you would change:
case XK_Up:
foo();
to
case XK_Up:
case XK_KP_Up:
foo();
No special case needed.
>
> This introduction of new keysyms may cause some problems
> with existing applications, but it is hoped that most X
> programs should be able to overcome these incompatibilities
> via the translation table mechanism.
>
>Give me a break. (If you require every X user to learn the translation table
>mechanism, you're severely limiting the potential number of X users.)
I concede this point. Another solution is to use xmodmap.
Backwards compatibility is not a strong point of this proposal.
> 3. New Keysyms
>
> Finally, there is no
> Page Up or Page Down keysym defined.
>
>Yech-o. Use XK_Prior and XK_Next.
It's a toss up in my mind. Prior and Next definitely would be better existing
applications.
> The PC/AT Keyboard does not have a unshifted glyph on the
> center keypad key (numeric 5). For the sake of consistency
> the existing KP_Space keysym should be used here.
>
>Why not use XK_VoidSymbol, since the keypad 5 in page control mode
>does nothing on DOS machines anyway? Inserting a space char may confuse
>users.
You're probably right here. The more I think about it, the space is
sort of silly.
>
>Mike, in my X applications, the concept of the Caps Lock key is essentially
>transparent. That is, when the Caps Lock is in the active state, my
>applications see "A" rather than "a" (or XK_A rather than XK_a). This
>means that my code doesn't have to program special cases for the Caps Lock
>key. This makes my job easier than it would have to be otherwise. Now, why can't
>the Num Lock key work much the same way? In other words, why can't your
>proposal make the Num Lock function essentially transparent to my application,
>e.g., through XLookupString() and the associated functions?
>
I absolutely believe the Num_Lock key should act just like the Caps Lock
key. One thing that should be done is the Num_Lock should be given a
standard spot in the modifier table. This is yet another problem which
everyone is solving differently. Sigh.
>If my code sees an XK_Up, it will know that an Up Arrow key was pressed,
>whether my code is running on an X terminal, a non-PC workstation or
>a PC-based workstation? If my code sees XK_Insert, it will know the
>Insert key was hit (except for an HP, but that's another matter). Millions of
>DOS users seem to handle the Num Lock concept just fine. Why not use
>that for PC-based UNIX systems as well? (An added benefit is that this
>will make it easier for DOS users to migrate to UNIX, and I suspect that
>a large number of SCO customers are migrating from DOS to UNIX, so you
>want to encourage this.)
Yes, and a large number of DOS Developers are migrating to UNIX as
well and the one question I keep on seeing over and over again is:
"How do I tell the difference between the regular arrow key and the
keypad arrow key?"
The philosophy is that every Keytop (engraving) on the keyboard should
have a unique X Keysym associated with it. This is why there is a
XK_Shift_L as well as a XK_Shift_R.
>Please don't take this personally.
Not at all. Thank you for your comments.
>It just seems that using
>the Num Lock key the way it was designed (for better or worse) is
>a LOT easier than adding in new arrow keys when we already have arrow
>keys.
I think if you go back and look at Appendix E of the Red (Purple?) book
you'll see why I decided to try to add some new Keysyms. I strongly
believe that every key on the keyboard should have a unique identifier.
If we only use the Num_Lock key, then it becomes almost impossible to
differentiate between the keys unless you look at the Keycodes. Then
you have an even more system specific case. In the long run, new
Keysyms will provide a more consistent solution.
mp
------
Mike Patnode The Santa Cruz Operation
Software Engineer 400 Encinal Street
{ucscc,uunet}!sco!mikep mikep@sco.COM P.O. Box 1900
(408) 458-1422 Santa Cruz, CA 95061
--
Mike Patnode The Santa Cruz Operation
Software Engineer 400 Encinal Street
{ucscc,uunet}!sco!mikep mikep@sco.COM P.O. Box 1900
(408) 458-1422 Santa Cruz, CA 95061pete@iris49.UUCP (Pete Ware) (01/11/91)
> "How do I tell the difference between the regular arrow key and the > keypad arrow key?" > > The philosophy is that every Keytop (engraving) on the keyboard should > have a unique X Keysym associated with it. This is why there is a > XK_Shift_L as well as a XK_Shift_R. > I think if you go back and look at Appendix E of the Red (Purple?) book > you'll see why I decided to try to add some new Keysyms. I strongly > believe that every key on the keyboard should have a unique identifier. > If we only use the Num_Lock key, then it becomes almost impossible to > differentiate between the keys unless you look at the Keycodes. Then > you have an even more system specific case. In the long run, new > Keysyms will provide a more consistent solution. Doesn't Appendix E (on pg 643 in the 2nd edition) in the description of the common approach explicitely suggest "folding likely aliases into the same keysym?" The "common approach" philosiphy is not to have a unique Keysym associated with every engraving on a keyboard. Perhaps the port to X can be viewed as an opportunity to clean up old hacks? I guess I'm not being very sympathetic towards being backward compatible. --pete Pete Ware / Biosym / San Diego CA / (619) 546-5532 uucp: scripps.edu!bioc1!pete Internet: bioc1!pete@scripps.edu
stripes@eng.umd.edu (Joshua Osborne) (01/11/91)
> > I think if you go back and look at Appendix E of the Red (Purple?) book > > you'll see why I decided to try to add some new Keysyms. I strongly > > believe that every key on the keyboard should have a unique identifier. > > If we only use the Num_Lock key, then it becomes almost impossible to > > differentiate between the keys unless you look at the Keycodes. Then > > you have an even more system specific case. In the long run, new > > Keysyms will provide a more consistent solution. In article <9101101641.AA06324@iris49.biosym.com>, pete@iris49.UUCP (Pete Ware) writes: > Doesn't Appendix E (on pg 643 in the 2nd edition) in the description > of the common approach explicitely suggest "folding likely aliases > into the same keysym?" The "common approach" philosiphy is not to > have a unique Keysym associated with every engraving on a keyboard. > > Perhaps the port to X can be viewed as an opportunity to clean up old > hacks? I guess I'm not being very sympathetic towards being backward > compatible. Well the hack that need to be cleaned is the keyboard, and it isn't going to happen. The ATish keyboards come in 2 basic flavors, one with a cursor pad, and one with no cursor pad. Under DOS both flavors' numeric keypad dubbles as a cursor pad. Without putting all the functionality of NumLock in the server (and loseing the ability to treat the numeric pad as the application wishes). There are two ways to do that, assume that KP_8 is K_Up, KP_6 is K_Left, and so on, which can be completly wrong on some numeric keypads (ones with 1 at the top left), or not match the engravings for ScrollUp and ScrollDown (KP_9 & KP_3 I think), or the entire pad. The other fix is to add KeySyms for KP_Up and friends and put them in the key maping table (I forget what it is called, the thing xmodmap plays with...) in some standard way (in the Caps Position, or a new spot). Both cause problems, which causes fewer? Is there another soultion that causes less then that? -- stripes@eng.umd.edu "Security for Unix is like Josh_Osborne@Real_World,The Multitasking for MS-DOS" "The dyslexic porgramer" - Kevin Lockwood "Don't over-comment" - p151 The Elements of Programming Style 2nd Edition Kernighan and Plauger
mouse@lightning.mcrcim.mcgill.EDU (01/24/91)
Dave Lapp writes about the problems raised by IBM AT keyboards (and clones thereof). I'm not going to get into the morass of whether we should or shouldn't use (for example) Next and Prev for PgUp and PgDn. But further text on the subject of NumLock provokes a response. > X11 expects that locking modifiers are mechanically locked. Since > most keyboards don't do this the server software must simulate this > behaviour. Generally the server 'eats' alternate upcode/downcode > pairs for CapsLock/ShiftLock keys to simulate this behaviour. The > server must use the keycode(s) which have been assigned to Lock > Modifier to decide when to do this. But X11 has a single Lock > modifier and this is normally used for Caps Lock. I think it should be possible to specify to the server exactly which keys should lock down. (It would be acceptable for this to be restricted to modifier keys.) I'm not sure whether this should be specified and/or stored in terms of KeyCodes or KeySyms. Of course, we could always just say that any KeySym whose name ends in "Lock" should lock :-) > Sooo problem one - How to identify NumLock as a modifier? Now about the same way Meta is? Any modifier bit bound to a Meta_L or Meta_R key is considered to be a meta modifier. Similarly, it would be easy enough to consider any modifier bit bound to a NumLock key as a NumLock modifier bit. > Any translation due to NumLock would take place in Xlib NOT in the > server. Agreed; as with Lock, the server simply maintains the modifier state; it doesn't actually do the modifications. > Problem two - Xlib needs to be changed to recognize the NumLock > modifier (given whatever convention is decided on) and act on it > appropriately. This requires a whole bunch of vendors changing their > Xlibs. What I would prefer to see is some sort of extensible mechanism in Xlib so that Xlib - regardless of whose - can be reconfigured in ways like this. (I know this is very vague. I'm not sure exactly what I want here myself.) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
kankkune@cs.Helsinki.FI (Risto Kankkunen) (01/30/91)
In mouse@lightning.mcrcim.mcgill.EDU writes: >> Problem two - Xlib needs to be changed to recognize the NumLock >> modifier (given whatever convention is decided on) and act on it >> appropriately. This requires a whole bunch of vendors changing their >> Xlibs. > >What I would prefer to see is some sort of extensible mechanism in Xlib >so that Xlib - regardless of whose - can be reconfigured in ways like >this. (I know this is very vague. I'm not sure exactly what I want >here myself.) I'd like to see something along these lines. There is too much hardcoded information currently in XLookupString and its friends. It's no good saying that XLookupString is just one convenience routine, and if it doesn't suit your application, translate the codes yourself. This would make every program use different conventions and it would be a pain to the user. I'd like to be able to specify with xmodmap which modifiers are tied to which keys or key combinations. I could say xmodmap - <<EOF modifier 1 = none modifier 2 = Shift modifier 3 = Meta modifier 4 = Shift+Meta Modifier 5 = NumLock EOF and then use the first keysym for normal keys, second for shifted, third for meta-combinations, fourth for shift+meta and fifth for numlock. There are many technical problems with this, but I think it shows what I'm aiming at. The meaning of the different "columns" in the keymap table should be user specifiable and dynamically changeable. What do you think? Risto Risto Kankkunen kankkune@cs.Helsinki.FI (Internet) Department of Computer Science kankkunen@finuh (Bitnet) University of Helsinki, Finland ..!mcsun!uhecs!kankkune (UUCP)