I was getting strange extra keycodes for some keys. The PGUP key would include a "/", the PGDN would open a menu, and up and right arrow did similar. After a year of fighting this (it made 2.6 unusable, so I kept running 2.4) I finally found the cause. Both kbd driver and evdev are responding to the same keyboard. Only discovered this after reading all of the xorg Changelog and getting a clue (they have known about this for years), and then grepping all the keycodes to find all possible sources for the keycodes that xev was reporting.
Because evdev also gets used for two power buttons and the mouse, it shows up in the logs anyway.

When xorg.conf specifies using "kbd" as the keyboard driver.
The kbd driver will be loaded, and the mapping will be set to the xfree86 keycode symbols.

Then HAL will discover the keyboard and load evdev as a keyboard driver. It does not notice that there already is a keyboard driver.

For every keypress, both evdev and kbd respond with keyboard events. Most evdev keycodes are not understood because the keyboard mapping is setup by kbd. A few of the keycodes happen to look valid, and those give extraneous responses.

There are four bugs here.
1. HAL starts a new driver for a device that already has one. Perhaps kbd needs to grab the device.
2. evdev does not check that the device is already in use
3. kbd has no way (that I know of) to fend off evdev, such as grabbing the device.
4. When HAL starts evdev for the keyboard, it does not change the keyboard mapping.

I would like to use kbd driver again, because evdev is not reporting keycodes for my internet buttons (Logitech Internet keyboard).

Questions:
Are there any known solutions for the four bugs listed?
I have not found any by internet search.

Are there docs for configuring HAL ?
How do you stop it from loading the evdev keyboard driver? (aside from blind mangling the config files).

Is there something special (or a known bug) concerning getting Logitech Internet keyboard to respond with usable keycodes (at least to xev)?

I have tried Option "Model" "logiik"
and it is being ignored, as far as I can tell. There is no difference in the keycodes reported to xev from using
Option "Model" "pc104".

I have no idea what using evdev as a keyboard model is "supposed" to do. I have not found any docs that describe this.
Option "Model" "evdev".

I could use general solutions because there are two machines, with differing hardware, and I am only giving details for the easy one.

Hi,

One option would be to completely disable hal for X. You can achieve this by adding to the ServerFlags section. Another is to mess with HAL files; I can't help you there, as HAL is dropped from Getnoo, so I got no way to test.
As for your evdev related problem, a quick google search found this, could it help?

Serafean

1 members found this post helpful.

Thank You. Maybe not directly applicable because it is different keyboard. But it has some links to check out. Cannot flag this as solved. There will be a long pause while I look through all the links.

Do not want to totally lose HAL, because it does some other things too, like auto-mount cdrom and memory sticks.

Is there really no way to specifically tell HAL to leave the keyboard alone.

The AutoAddDevices option in Xorg.conf is supposed to do that.

I can not consider this question answered unless the answer can specifically stop the keyboard driver being loaded by HAL, without stopping other devices like usb memory sticks, and cdrom mounts.
That is what I mean by specific, how to tell HAL that the keyboard driver is not its concern, and not how to kill HAL altogether.

Hi,

HAL takes care of any hardware that changes while the system is running.
X takes care of catching input events and passing them along to clients, then rendering changes on screen.

From the X manual : This means that HAL will still be running, taking care of CDROMS and memory cards, but X will ignore any input devices reported by HAL. Instead you will have to specify a keyboard and mouse InputDevice section, and that will be used. Which means that HAL will detect the keyboard, and tell X about, but X will ignore anything HAL tells it, using its own configuration file.
This option will NOT kill HAL.

1 members found this post helpful.

Thank you for that information. That is a little clearer stated that way. Thank You.
I may get a chance to try that later next week. It will only work if none of the other devices used by X are installed by HAL discover-and-report (camera, etc.), and it will take some testing to verify.

However, there are four questions/bugs, and I want to keep this thread open.
I especially am interested in configuring HAL itself, not messing with X to work around it.
It seems there is no public knowledge on how to configure it or control HAL.

Update 7/5/2011:
Tried disabling "AutoAddDevices", and it also refused to load evdev for two power buttons that HAL had found.
No other bad effects so far. Would have to figure out how to setup Xorg.conf to load evdev for power buttons. I do not know which is worse, right now. Both ways I have devices and keys that do not work.