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