"s" "d" and "f" don't type in console

krose · 05-09-2008, 08:03 AM

In zsh everything types just fine. However, in all other shells (bash, mysql, etc), and in the non-X console, the lower-case "s", "d" and "f" keys won't type. I only noticed this when trying to do some work in mysql (pretty tough without those three keys), and it must have worked at some point or I would have had a hard time switching to zsh (note the s). I switched to a dvorak layout (via the gnome keyboard app) and the "s", "d" and "f" keys still wouldn't type (though they were mapped to other physical keys).

I'm running gnome in Heron on a Dell D620 laptop.

Any ideas appreciated. I don't know where to start and I'm not getting very far googling for "s", "d" and "f" or "keys won't type".

Cogar · 05-09-2008, 02:13 PM

You might try plugging in a separate keyboard via the USB port, which will determine whether the keyboard in your laptop is starting to go (or has gotten contaminated). Is it a hardware problem? Hard to say. Still, keyboards (and mice) do wear out and I have seen some of them do some very unexpected things when they are in the process of "going." Good luck in any case.

krose · 05-09-2008, 03:36 PM

I'll give that a try, but I don't think that's it for three reasons:

First, these three letters always work fine in zsh, and always don't in bash and mysql. This is consistent in both X and at the system console. It's also consistent whether I change /etc/passwd and login in bash and then start a zsh session (via a script since I can't type an "s" while in bash), or login in zsh and then start a bash session.

Second, changing to a dvorak keyboard layout still had a problem with "s", "d" and "f", even though these letters were mapped to different physical keys.

Third, there's never a problem with captital "S", "D", or "F" -- only with the lower case letters.

Wierd, huh? I'm pretty sure it's due to some software keymapping that's incorrect but being corrected by zsh. However, I don't know where to start looking for this.

Thanks though.

krose · 05-17-2008, 11:17 AM

Haven't figured this out yet. Any ideas??

raskin · 05-17-2008, 11:21 AM

What do showkeys and xev say about system's comprehension of your keystrokes?

krose · 05-19-2008, 08:31 AM

I created executable scripts for "xev" and "showkey" since I can't type these without an "e" key! For each of these tests I typed "s", "d", and "f" in succession. The "showkey" tests were conducted in a console via ctrl-alt-f1, and the xev were in a terminal window in X.

Sorry for the lengthy paste that follows.:

showkey produces the same output under zsh and bash, except that letters appear when typed in zsh but NOT in bash:

Code:

0x9c 
0x1f 
0x9f 
0x20 
0xa0 
0x21 
0xa1

xev under zsh. Letters DO appear when typed:

Code:

KeyPress event, serial 34, synthetic NO, window 0x2600001,
    root 0x5d, subw 0x0, time 3741141, (192,24), root:(235,380),
    state 0x0, keycode 39 (keysym 0x73, s), same_screen YES,
    XLookupString gives 1 bytes: (73) "s"
    XmbLookupString gives 1 bytes: (73) "s"
    XFilterEvent returns: False

KeyRelease event, serial 34, synthetic NO, window 0x2600001,
    root 0x5d, subw 0x0, time 3741268, (192,24), root:(235,380),
    state 0x0, keycode 39 (keysym 0x73, s), same_screen YES,
    XLookupString gives 1 bytes: (73) "s"
    XFilterEvent returns: False

KeyPress event, serial 34, synthetic NO, window 0x2600001,
    root 0x5d, subw 0x0, time 3742722, (192,24), root:(235,380),
    state 0x0, keycode 40 (keysym 0x64, d), same_screen YES,
    XLookupString gives 1 bytes: (64) "d"
    XmbLookupString gives 1 bytes: (64) "d"
    XFilterEvent returns: False

KeyRelease event, serial 34, synthetic NO, window 0x2600001,
    root 0x5d, subw 0x0, time 3742836, (192,24), root:(235,380),
    state 0x0, keycode 40 (keysym 0x64, d), same_screen YES,
    XLookupString gives 1 bytes: (64) "d"
    XFilterEvent returns: False

KeyPress event, serial 34, synthetic NO, window 0x2600001,
    root 0x5d, subw 0x0, time 3744238, (192,24), root:(235,380),
    state 0x0, keycode 41 (keysym 0x66, f), same_screen YES,
    XLookupString gives 1 bytes: (66) "f"
    XmbLookupString gives 1 bytes: (66) "f"
    XFilterEvent returns: False

KeyRelease event, serial 34, synthetic NO, window 0x2600001,
    root 0x5d, subw 0x0, time 3744363, (192,24), root:(235,380),
    state 0x0, keycode 41 (keysym 0x66, f), same_screen YES,
    XLookupString gives 1 bytes: (66) "f"
    XFilterEvent returns: False

xev under bash. The same except for times, though letters DON'T appear:

Code:

KeyPress event, serial 34, synthetic NO, window 0x2600001,
    root 0x5d, subw 0x0, time 4030078, (166,-9), root:(220,347),
    state 0x0, keycode 39 (keysym 0x73, s), same_screen YES,
    XLookupString gives 1 bytes: (73) "s"
    XmbLookupString gives 1 bytes: (73) "s"
    XFilterEvent returns: False

KeyRelease event, serial 34, synthetic NO, window 0x2600001,
    root 0x5d, subw 0x0, time 4030178, (166,-9), root:(220,347),
    state 0x0, keycode 39 (keysym 0x73, s), same_screen YES,
    XLookupString gives 1 bytes: (73) "s"
    XFilterEvent returns: False

KeyPress event, serial 34, synthetic NO, window 0x2600001,
    root 0x5d, subw 0x0, time 4030709, (166,-9), root:(220,347),
    state 0x0, keycode 40 (keysym 0x64, d), same_screen YES,
    XLookupString gives 1 bytes: (64) "d"
    XmbLookupString gives 1 bytes: (64) "d"
    XFilterEvent returns: False

KeyRelease event, serial 34, synthetic NO, window 0x2600001,
    root 0x5d, subw 0x0, time 4030827, (166,-9), root:(220,347),
    state 0x0, keycode 40 (keysym 0x64, d), same_screen YES,
    XLookupString gives 1 bytes: (64) "d"
    XFilterEvent returns: False

KeyPress event, serial 34, synthetic NO, window 0x2600001,
    root 0x5d, subw 0x0, time 4031360, (166,-9), root:(220,347),
    state 0x0, keycode 41 (keysym 0x66, f), same_screen YES,
    XLookupString gives 1 bytes: (66) "f"
    XmbLookupString gives 1 bytes: (66) "f"
    XFilterEvent returns: False

KeyRelease event, serial 34, synthetic NO, window 0x2600001,
    root 0x5d, subw 0x0, time 4031486, (166,-9), root:(220,347),
    state 0x0, keycode 41 (keysym 0x66, f), same_screen YES,
    XLookupString gives 1 bytes: (66) "f"
    XFilterEvent returns: False

raskin · 05-19-2008, 02:53 PM

Hm, what is your locale and $TERM? Keycodes seem correct..

krose · 05-20-2008, 11:22 AM

Same for zsh and bash:

Code:

locale

LANG=en_US.UTF-8
LC-CTYPE="en_US.UTF-8"
LC-NUMERIC="en_US.UTF-8"
LC-TIME="en_US.UTF-8"
LC-COLLATE="en_US.UTF-8"
LC-MONETARY="en_US.UTF-8"
LC-MESSAGES="en_US.UTF-8"
LC-PAPER="en_US.UTF-8"
LC-NAME="en_US.UTF-8"
LC-ADDRESS="en_US.UTF-8"
LC-TELEPHONE="en_US.UTF-8"
LC-MEASUREMENT="en_US.UTF-8"
LC-IDENTIFICATION="en_US.UTF-8"

echo $TERM

xterm

raskin · 05-20-2008, 11:50 AM

I fail to see what is wrong.. And if you write a C program to read from console, and run it from bash and from zsh, does it read the sdf letters?

krose · 05-30-2008, 09:59 PM

I wrote a simple python program:

Code:

print raw_input()

and a simple C program:

Code:

#include <stdio.h>
main() { 
  while(1) {
    printf("%c\n", getchar());
  }
}

In both cases, the programs function just the same in zsh and in bash. In fact, then running these programs in the bash shell, the "s", "d" and "f" keys appear when typed, and again when printed back to stdout. After exiting the programs the "s", "d" and "f" keys again fail to appear (or have any affect) when in the bash shell (or other interactive shells like python or mysql).

raskin · 05-30-2008, 11:32 PM

Could you try to update/downgrade ncurses/termcap/terminfo/readline packages? The main idea is to have a package downloaded and hash-checked.. Looks like console description files got corrupted or something like that... Some checks maybe worth trying:

Code:

TERM=dumb bash

- should suppress intelligence being applied to trating console input.

Code:

cat ~/.inputrc /etc/inputrc

- to look if your readline settings are far from sane (bash, mysql, python.. use readline; zsh uses zle - its own command-line editor - to make possible its slightly-smarter-than-bash-until-something-fails sompletion; your programs used direct stdin reading without processing and it seems to work). Install rlwrap and run

Code:

rlwrap ./your-program

(your program should now read and print lines in loop until EOF, somewhat like cat). If it adds input history to your program but kills ‘‘s’’ key, readline/ncurses is in charge. Also try cat - how does it react on the broken keys? And when rlwrapped?

AbsoluteMonkey · 05-30-2008, 11:42 PM

I bet it's your font. Change the font for your shell. Sounds weird I know. I have a similar problem with an IBM windows machine. A certain program running on it wouldn't take a quote or double quote in an input field unless you typed the key three times, then the quotes would show up. Come to find out, the font somehow doesn't like the graphics card.