On Thu, 2009-05-28 at 23:52 -0700, Bill Campbell wrote: > On Thu, May 28, 2009, MHR wrote: > <snip> > > > >Surprise: the new keyboard has exactly the same problem - no response > >from the number pad. > > > >Actually, that's not entirely accurate. The num lock and the Enter > >key both work, but the 5 key produces some control combination I don't > >recognize (seems to behave something like ^V of a previously ^X'd > >clipboard copy, unrelated to the current input), and the + key which > >seems to produce something like ^V^V, or "highlight the current > >terminal line" or something, but none of the other keys work at all. > > You might want to use the xev program under X11 to see what key > codes are being seen by the system. I had to create ~/.Xmodmap > to map the numeric keypad on my Microsoft Natural keyboard to > always send numbers on Mac OS X 10.4.x otherwise python curses > applications don't do the right thing. Not sure if this applies because I've a "MS" version. But maybe this wil yield a clue? When I hook it up and use it, in a VT, there are some extra codes emitted that spawns a message saying the code is unrecognized and I should setkyecodes to fix it. In my case the code is 0xe001. These same messages would appear under X in a terminal. This fixed it for me. # cat bin/FixKb #!/bin/bash setkeycodes 0xe001 1 My thinking is that to conserve battery, or account for a sleeping/hibernating system, this code is emitted as a "wake up". Anyway, my suggestion is that some review of some man pages might provide the real solution. dumpkeys loadkeys showkey getkeycodes setkeycodes There might be a couple I forgot, but some of those, IIRC, have layouts defined. Maybe one of them fixes your issue. > > Bill HTH -- Bill (the other one :)