[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Consistant Keyboard Configuration (was Re: Another packages wishlist)

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

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
     - 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
      - 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
      - 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
          + 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
branden@ecn.purdue.edu         |    doing it right."
roger.ecn.purdue.edu/~branden/ |    -- Woody Allen

Attachment: pgpcdyYD0sFRb.pgp
Description: PGP signature

Reply to: