[CentOS] Problem with Logitech wireless keyboard EX110

Fri May 29 15:03:35 UTC 2009
William L. Maltby <CentOS4Bill at triad.rr.com>

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  :)