Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!src.honeywell.com!msi.umn.edu!cs.umn.edu!sialis!dmshq!com50!pai!erc From: erc@pai.UUCP (Eric F. Johnson) Newsgroups: comp.windows.x Subject: Re: PC/AT Keyboard X Keysym Proposal - R.F.C. Keywords: Some F. Comments; Use Num Lock Message-ID: <1607@pai.UUCP> Date: 7 Jan 91 17:44:58 GMT Organization: Boulware Technologies, Inc., Burnsville, MN Lines: 250 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