After a lot of googling I found a wonderful article on handling "special" keys
in X-windows. It's going to be my bible for re-mapping keys in X.
I include it here because others may find it useful.
Larry Alkoff N2LA
Re: Consistant Keyboard Configuration (was Re: Another packages wishlist)
To: [EMAIL PROTECTED]
Subject: Re: Consistant Keyboard Configuration (was Re: Another packages wishlist)
From: Branden Robinson <[EMAIL PROTECTED]>
Date: Wed, 1 Mar 2000 06:33:05 -0500
In-Reply-To: <[EMAIL PROTECTED]>; from [EMAIL PROTECTED] on Tue,
Feb 29, 2000 at 06:56:53AM -0800
Mail-Followup-To: [EMAIL PROTECTED]
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
User-Agent: Mutt/1.1.5i
On Tue, Feb 29, 2000 at 06:56:53AM -0800, Jim Lynch wrote:
> And I have a request too...
>
> At one point there was a group working on making the keyboard configuration
> of debian consistant between x and console. Does this group still function
> and contribute to debian?
>
> Slink was great for its keyboard configuration... potato is so far
> horrible and broken in some ways. Consistancy between console and
> X is badly broken, and no one seems to be talking about that.
>
> If anyone knows about this group or is/was working with them, could
> you point me to them? Or better yet, if they are inactive, can someone
> reactivate them?
>
> You can consider this a Request For Discussion to add consistancy wrt
> key mapping between x, console, telnet, ssh and as many other things
> as possible that would make sense to have consistant mapping, to
> the debian policy document.
This is because of two things:
1) Yann Dirson keeps horking the console-data package in new and exciting
ways; one example is the release(s) that set your keymap to "azerty"
regardless of what you told the dialogs. I gather from certain people
who have reason to know that Yann doesn't know how to use debconf
correctly.
2) There was a period of time where the xterm terminfo data in the
ncurses-base package was badly out of sync with the xterm binary package.
That was fixed weeks ago.
I have no power over console-data, so I can't help you there.
But if you think X is misunderstanding the keyboard, you should file a
bug...if and only if you have done your homework and can file a bug report
with useful information in it.
1) Install the xcontrib package and use the "xev" tool to determine what
keycodes and keysyms are being generated by the problematic keys.
2) If what xev says makes sense to you, and yet your X clients (xemacs,
xterm, what have you) are doing the wrong thing, this is NOT, repeat
NOT, a problem with the X server and its notion of your keyboard. It's a
problem with the X client. Skip to step
3) If what xev doesn't make sense, then the X server is confused about
your keyboard. There are several things to check:
- Are you using XKB? Most people should. If you have "XkbDisable"
uncommented in the keyboard section of your /etc/X11/XF86Config,
you're not using XKB.
+ Do your XKB settings make sense? Here are mine, which make
perfect sense for North American qwerty keyboard users:
XkbRules "xfree86"
XkbModel "pc104"
XkbLayout "us"
(If you're not using a "Windows" keyboard, you can change the
"pc104" to "pc101").
+ Are you using /etc/X11/Xmodmap or $HOME/.Xmodmap to override what
XKB thinks about your keyboard? If so, cut it out. You should
only be using xmodmap stuff with XKB if you really know what you're
doing.
- If you're not using XKB, then you're relying on the console
keymap, which is often wrong for the reason given above. At the
very least, you'll probably have to uncomment an appropriate piece
of the default /etc/X11/Xmodmap file to get the backspace and
delete keys working correctly.
4) You're having an X client problem. How you address this depends on
the client. A favorite gripe of people is xterm. Unfortunately,
there are many places where things can go wrong with xterm.
- It can receive the wrong keysyms from the X server; to debug this,
go back to step 3, or even step 1. All X clients will receive the
same keysyms from the server, so you can use xev to find out what
key events are being generated.
- xterm can be translating the key events into the wrong terminal
control sequences; this part is all about X resources. The default
xterm X resources in /etc/X11/Xresources/xterm are known to work
for 3.3.6-4, there are only two; backspace generates ASCII 127 and
delete generates ESC [ 3 ~). If you have stuff in any X dotfiles
in your home directory that look like the stuff in
/etc/X11/Xresources/xterm, you might be shooting yourself in the
foot.
- Whatever is running in the xterm (like the shell) can be getting
bogus information from the terminfo file for the terminal type that
xterm is using. Make sure you're using the latest ncurses-base
package. If you're not using TERM=xterm, make sure you understand
why.
- For some keys, due to frustrating historical practice, there is
simply going to be incompatibility with the Linux console. Why?
Because xterm was initially written to emulate a VT100 terminal.
PC keyboards have many more keys than a VT100. The PC keyboard
resembles a VT220 keyboard much more closely. That's why Linus
based the kernel console driver on VT220 emulation. If you want
xterm to behave more like the Linux console, use the terminal type
"xterm-vt220". What keys are affected by this historical
incompatibility?
+ Backspace, or whatever you have engraved on the key in the
upper-right section of the alphabetic section of your keyboard.
All DEC VT series terminals generate ASCII 127 when this key is
pressed. Everybody who presses that key expects a destructive
backspace. At some point over the years, a lot of stupid
people assumed that, for this key, the key engraving should
correspond to a similarly names ASCII code; namely, ASCII 8 or
"BS" (backspace). This is just plain dumb because what matters
is user expectations, not the enforcement of some kind of
mapping between ASCII and key engravings non-glyph keys. What
do you do about the function keys, for instance. Bottom line:
the "backspace" key, the one in the upper-right of the
alphabetic section, should generate ASCII 127 ("DEL") if you're
emulating a DEC VT-series terminal. End of story. No
exceptions. If you disagree, eat a gun. The real tragedy is
that some point, the misconception I've discussed crept into
termcap and terminfo data for xterms, and people got used to
the backspace key (engraved with "Delete" on VT terminals,
Macintoshes, and some other keyboards) generating ASCII 8 (or
control-H) instead of ASCII 127 (or control-?), in flagrant
incompatibility with every DEC VT terminal ever made, one model
of which (the VT100) xterm was expressly written to emulate
from its very inception in 1984. The good news is, Tom Dickey,
the upstream xterm maintainer, is taking steps to move
everybody back to the Good Side of the Force with XFree86 4.0.
Debian's Keyboard Policy has anticipated that move. So, if
people do things correctly, there is no incompatibility between
the Linux console and xterm.
+ Delete. This is the thing on the "editing" keypad of a PC
keyboard, along with "Insert", "Home", "End", "Page Up", and
"Page Down". The violence done to the backspace key had
fallout here, with this key getting perverted to ASCII 127
instead of the control sequence ESC [ 3 ~ like every DEC VT
terminal ever made. Again, if people do things correctly,
there is no incompatibility between the Linux console and
xterm. (Actually, the DEC VT100 series had no editing keypad at
all; just the alphabetic section and a numeric keypad.)
Furthermore, the key engravings on this part of the keyboard
are different on a VT220 or later and a PC, but there is
sensible and de facto standard mapping from one to the other,
which works fine if people don't butcher the delete key with
ASCII 127.
+ The numeric keypad. This is a place where incompatibility is
probably going to have to be accepted. Why? Because they're
laid out differently, for one thing. Instead of the
double-height plus key that PC keyboards have, DEC terminals
have two normal-sized ones, a minus and a comma. Also, instead
of "Num Lock", slash, asterisk, and minus across the top row,
DEC terminals have "PF1", "PF2", "PF3", and "PF4". (PF means
"Pad Function".) These were the only function keys the VT100
had; the 220 and later had a complete row of F-keys similar to
the PC keyboard along the top as well. Furthermore, whereas
the "Num Lock" key on a PC toggles the keypad between numeric
mode a mode duplicating the features of the editing keypad and
cursor keys, the DEC terminals toggled between "keypad numeric
mode" and "keypad application mode". Whereas the former maps
fairly cleanly to a PC keypad with Num Lock on, the latter does
stuff utterly differently. A DEC VT keypad in application mode
generates control sequences totally different from the editing
or cursor keypads. This makes sense, because the keys aren't
engraved with "Insert", "Delete", and so forth on a VT keypad
like the PC keys are. So, you get a choice on your PC: you can
either act like a real VT, and thus confuse users who expect
the numeric keypad keys to do what their engravings lead you to
believe with the Num Lock off, or you can discard these "keypad
application" functions that are present in the VT terminals,
and possibly lose functionality from applications that expect a
real VT terminal. I think Tom Dickey is working on trying to
get some kind of modal behavior into xterm where you can switch
back and forth between these alternate behaviors of the numeric
keypad from a menu in xterm. I don't know how well this has
been implemented yet.
+ The function keys along the top row of the keyboard. These
don't even exist on a real DEC VT100, but they do on the 220 (and
later models). Here we get more confusion. On a real DEC, F1
through F5 are used exclusively for communicating with the
terminal's firmware for configuration, and no information that
these keys have been pressed is ever sent to the remote host.
So, in a sense, these keys "don't exist" on a real VT terminal
for purposes of communicating with an application. What most
people seem to have done is to map the PF keys from the numeric
keypad to F1-F4 on the PC. This is a reasonable compromise, and
certainly better than hijacking the Num Lock key away, which
you'd have to do if you tried to do a physical mapping between
the VT keyboard and the PC. What is done about F5 seems to be
a bit up in the air.
+ Where PC keyboards have "Print Screen", "Scroll Lock", and
"Pause", VT100's have no keys (no top row, remember?) and
VT220's and later have only two keys: a double-wide "Help" key
and a "Do" key.
+ Finally, VT220 and later keyboards have four additional
function keys above the numeric keypad where most PC keyboards
have the LED's for Caps, Num, and Scroll Lock.
Clear enough? I'll keep a copy of this message and send it to every
brick-stupid person with a thumb in their mouth who doesn't understand why
terminal emulation can be a difficult issue. No, folks, your computer
doesn't have a telepathic interface.
What the world COULD use is some standardization of the areas I described
above that are still in flux. I invite anybody wishing to participate in
such an effort to debian-x. If anything happens I'll invite Tom Dickey in
on the action; as upstream maintainer of both ncurses and xterm, he's one
of the few real experts on this matter.
For more information about DEC VT terminals, see: <http://vt100.net/>.
--
G. Branden Robinson | Somebody once asked me if I thought sex
Debian GNU/Linux | was dirty. I said, "It is if you're
[EMAIL PROTECTED] | doing it right."
roger.ecn.purdue.edu/~branden/ | -- Woody Allen
Larry Alkoff N2LA - Austin TX
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
