Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!deccrl!news.crl.dec.com!shlump.nac.dec.com!netrix.nac.dec.com!lan_csse From: lan_csse@netrix.nac.dec.com (CSSE LAN Test Account) Newsgroups: comp.windows.x Subject: Re: How do I remap the keyboard? Keywords: XGetKeyMap Keyboard Xwindows Message-ID: <22171@shlump.nac.dec.com> Date: 18 Apr 91 20:25:03 GMT References: <9104102309.AA00552@lightning.McRCIM.McGill.EDU> <24228@well.sf.ca.us> Sender: news@shlump.nac.dec.com Organization: Digital Equipment Lines: 104 Hi again. Some days ago I wrote: >>> We have an application that needs to redefine the keys on the >>> keyboard to be different from the default. It is obvious that X >>> contains support for this; My mailbox soon filled up with a lot of messages of the form "If you learn anything on the topic, please tell me, too." So here's what I know now (including quite a few further admissions of ignorance ;-)... First, one thing I suspected is true: The keycode->keysym mapping seems to be done in the server, so changes there are global to the display (or to however many displays a given server is running). Meanwhile, the keysym->string mapping is done inside the application (actually inside the X library inside the application in most cases), so changes there are on a per-window (well, actually per-instance-of-the-X-library) basis. This is all fine, but it helps to know how it works. The question about defining shift-comma and shift-dot got answered by several people: xmodmap keysym comma = comma less xmodmap keysym period = period greater or xmodmap -e 'keysym comma = comma less' -e 'keysym period = period greater' if you want to save a bit of cpu time. I'd tried lots of guesses as to what xmodmap's syntax was, and never guessed this. I also can't quite correlate this with what xmodmap's manual page describes as its syntax. I mean, why are "comma" and "period" replicated on both sides of the '='? How does it know that I'm telling it to change shift-comma, say, rather that just comma or ctrl-comma or meta-comma or ...? What the @#$@# *is* the syntax of this little beastie? Meanwhile, on the keysym->string translation, several people pointed me at the appropriate clause in the FAQ files. In reading it, it quickly became obvious why grep hadn't found it for me; I would have never guessed the terminology, and I can hardly recognize the entry as an answer to my question. But with the hint that it was the answer, I did a whole lot of experimenting. One of the first things was to discover that when the xterm manual page says "The xterm application reads the .Xdefaults file during startup ..." it is lying through its teeth. I wasted a couple of hours modifying .Xdefaults, and nothing I did had any effect whatsoever on new xterms. I became suspicious, did a "ls -lu .Xdefaults", started a new xterm, and repeated the "ls -lu", and verified that the access time hadn't changed. So xterm doesn't open .Xdefaults at all. A bit more experimenting verified that if I kill X off and restart it, xterm then uses the contents of .Xdefaults. Thus .Xdefaults is cached inside the X server, and xterm gets the info from there. This also explains why xterm is to incredibly slow when started across a SLIP link; the entire .Xdefaults file is stuffed across the link for every xterm. A line monitor verifies this; you can see the data flow by. Sigh. But I did stumble across another hint that you can say: setenv XENVIRONMENT foo and when xterm starts up, it will read foo as a resource file. I tried this, and guess what? It actually works as advertised. I created a foo file with contents like: xterm*scrollBar: true xterm*Translations: #override \ F1 : string("You touched F1") \n\ ... KP_0 : string("You touched KP_0") \n\ ... KP_F2: string("KP_F2\\n") \n\ ... Help : string("You touched Help") and ran an xterm. Inside that xterm, the keys generated the strings that you see above. So far so good. Well, not really, since this strikes me as incredibly bizarre syntax. I mean, why the '#' before the "override"? Why the "\n\" at the end of the lines? Where is this explained? Also, I'm blocked at what might be the most critical point: The above definitions define strings consisting only of printable ASCII characters. I need to get things like ESC and CR and NUL into the strings. So far, all my attempts have failed. I tried putting them literally into the quoted strings; I get off-the-wall error messages from xterm and the keys don't get redefined at all. I tried all sorts of escape sequences such as "\n", "\013", "#0A", , and "^J", and none of them generate the bits I want. They just toss out the backslashes and produce the printable chars inside the quotes. Does anyone have any idea what the incantations might be to include an arbitrary (preferably hex or octal) 8-bit byte into these strings? Should I perhaps hunt down the source code for xterm and analyze it? Should I just toss up my hands and write my own filter that reads keysyms and writes what I tell it? It sure seems that the folks who wrote xterm had this in mind, and it'd be a real waste to do it over again, but it's starting to look like figuring out how it works will turn out to take more time than it would have to write my own program... BTW, if there are any DECcies lurking hereabouts, it'd be interesting to hear how this might be done in a dxterm. Most of our intended applications involve Ultrix workstations, and since dxterm has all these bells and whistles to configure it like just about anything, it seems that there just might be a way to get dxterm to do it if xterm won't. Another possibility: Some of our important applications involve running tip inside the window talking out a port to a DOS system that is running pcanywhere, so what we need is to send IBM PC/DOS escape sequences down the line. It occurs to me that one solution would be a window that is specifically an emulation of a DOS keyboard/display. I've seen these running on Sun and AIX systems, but we want to run them on things like Ultrix and OSF workstations. This is a DECstation 3100, for instance. Is there any chance of such a DOS-window program for such systems? This is getting to be too many issues for a single article, so...