My keyboard has two keycodes from one keypress
 

Okay, so here I am, running Xev. My keyboard mostly works fine. I have a HP Pavillion Dv1000 and I'm running OpenSUSE. I've had the following problem on 3-4 other distros aswell.

-I hit "c" on my keyboard. Xev tells me I had two keyPress events, keycode 121 and keycode 54. 121 corresponds to the volume button.
-I hit "d" on the keyboard. Xev tells me that I had two keypress events, keycode 122 and keycode 40.
-I hit the "touchpad on" button. Xev tells me that I hit keycode 26, "e"

So the implications of this are that when I hit touchpad on, I also type the letter e. It also works in reverse for some reason. When I type "e", my touchpad toggles on/off.

Also, "c" mutes my volume, and "d" lowers my volume.

I'm not too worried about the touchpad error, because I plan on doing mostly programming in the shell, and I can LIVE with having to toggle on my mouse once in a while. The problem is the "c" and "d" thing.

The current fix is editing my .Xmodmap file to having keycodes 121 and 122 point to nothing. I really don't care about volume control. But here's the real problem that I need help with. I open up nano, and I type #include , but when I hit the "c" I get a newline. Same with d.
If i were to type it, i would get
Every time I hit a c or a d, i get a newline. I suppose that means nano decides 121 and 122 point to a newline character.

vi does something similar and doesn't work.

I can live with every other issue my keyboard has given me but not this. If someone can help me figure out how to change the way nano receives input, please tell me. Do I need to build nano myself and change somewhere in the source code where it talks about reading certain numbers?

I have no idea how to solve this, and in 20+ years of mucking about with computers I've never heard of this one.

But I do have two suggestions:

1. It's probably not a good idea to start a 2nd thread for something that seems to be a variation on the same problem in your first thread.

2. IF you have a known-good external keyboard and IF you can connect it to your computer, do so. If the problem does not exist with the external keyboard, it becomes local to the hardware keyboard and is likely a hardware or possibley a BIOS problem. If it persists with an external keyboard, then it is indeed a software problem.

After a year of trying to fix this I finally found the cause. There are two keyboard drivers running. Look in your /var/log/Xorg.0.log file (or similar name) for the keyboard driver responses and see if there is more than one set.

Most of the xorg docs talk about using the kbd keyboard driver. Old xorg.conf files will use the kbd driver. If you use the kdb driver the following will happen.

Xorg.conf will load the kbd driver and open the keyboard device, and the kdb xfree86 keycodes will be used for mapping.

HAL will discover the keyboard and load the evdev driver for the keyboard device.
It will not notice the kbd driver is already running.

For each keypress both drivers will respond.
The evdev driver will create an event giving a keycode using evdev symbol encoding.
These are misinterpreted using xfree86 keycode symbol encoding, resulting in most of them being ignored garbage, but some of them will look valid and will create visible garbage.
The kbd driver will create an event giving a xfree86 keycode encoding, which is the one that works.

Solution 1:
Change your /etc/X11/xorg.conf file to use the evdev driver for the keyboard.
It grabs the keyboard and prevents HAL from attaching a second driver to the keyboard. HAL will try to start evdev, but it will fail.
Include the line (or similar):
Option "Device" "/dev/input/event0"
Without the device line, the evdev from xorg.conf will fail with a message that there was no device specified.
Then later HAL will load evdev, but without any of the settings specified in the xorg.conf file (causing you to tear out the other half of your hair trying to find why your xorg keyboard config is being ignored by evdev).

Solution 2:
Change the HAL /etc files to not load the evdev driver for keyboards. I have not figured out how to do that yet.

Solution 3:
Fix the kbd driver to grab the keyboard and thus stop evdev from attaching a second keyboard driver. I have not figured out how to do this one yet either.

You can try
This has worked for me.

Option "AutoAddDevices" "false" might work, but would also stop mounting of my memory-stick, CD-ROM, etc., which is a real pain to do manually by any KDE method except Konsole.

Other options have also had bad side effects, like kbd driver parameters and serial port mouse being ignored.
Apparently auto xorg config, nor HAL, can not handle a serial port mouse.