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 :)
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
