After upgrading to today's changes in X branch I lost control over several keys of my T23 Thinkpad.
These are all arrow keys and the delete one.

Maybe some changes are to be made inside xorg.conf file ?

Here is mine if it helps:

<<<<<<<<<<<<<<<<<<<

Section "Files"
FontPath "/usr/share/fonts/X11/misc"
FontPath "/usr/X11R6/lib/X11/fonts/misc"
FontPath "/usr/share/fonts/X11/cyrillic"
FontPath "/usr/X11R6/lib/X11/fonts/cyrillic"
FontPath "/usr/share/fonts/X11/100dpi/:unscaled"
FontPath "/usr/X11R6/lib/X11/fonts/100dpi/:unscaled"
FontPath "/usr/share/fonts/X11/75dpi/:unscaled"
FontPath "/usr/X11R6/lib/X11/fonts/75dpi/:unscaled"
FontPath "/usr/share/fonts/X11/Type1"
FontPath "/usr/X11R6/lib/X11/fonts/Type1"
FontPath "/usr/share/fonts/X11/100dpi"
FontPath "/usr/X11R6/lib/X11/fonts/100dpi"
FontPath "/usr/share/fonts/X11/75dpi"
FontPath "/usr/X11R6/lib/X11/fonts/75dpi"
# path to defoma fonts
FontPath "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType"
EndSection

Section "Module"
Load "i2c"
Load "bitmap"
Load "ddc"
Load "dri"
Load "extmod"
Load "freetype"
Load "glx"
Load "int10"
Load "vbe"
EndSection

Section "InputDevice"
Identifier "Generic Keyboard"
Driver "kbd"
Option "CoreKeyboard"
Option "XkbRules" "xorg"
Option "XkbModel" "pc104"
Option "XkbLayout" "us"
EndSection

Section "InputDevice"
Identifier "Configured Mouse"
Driver "mouse"
Option "CorePointer"
Option "Device" "/dev/input/mice"
Option "Protocol" "ImPS/2"
Option "Emulate3Buttons" "true"
EndSection

Section "Device"
Identifier "S3 Inc. SuperSavage IX/C SDR"
Driver "savage"
BusID "PCI:1:0:0"
EndSection

Section "Monitor"
Identifier "Generic Monitor"
Option "DPMS"
HorizSync 28-51
VertRefresh 43-60
EndSection

Section "Screen"
Identifier "Default Screen"
Device "S3 Inc. SuperSavage IX/C SDR"
Monitor "Generic Monitor"
DefaultDepth 16
SubSection "Display"
Depth 1
Modes "1024x768"
EndSubSection
SubSection "Display"
Depth 4
Modes "1024x768"
EndSubSection
SubSection "Display"
Depth 8
Modes "1024x768"
EndSubSection
SubSection "Display"
Depth 15
Modes "1024x768"
EndSubSection
SubSection "Display"
Depth 16
Modes "1024x768"
EndSubSection
SubSection "Display"
Depth 24
Modes "1024x768"
EndSubSection
EndSection

Section "ServerLayout"
Identifier "Default Layout"
Screen "Default Screen"
InputDevice "Generic Keyboard"
InputDevice "Configured Mouse"
EndSection

Section "DRI"
Mode 0666
EndSection

You don'k now other consequenses. Group swich is not working and if youn unplug a USB mouse the server will crash, at least on my M6N. Reverted back to xorg-server-1.4.0-i486-2

Lucky me. I haven't upgrade to the latest XOrg

some keys didn't work here and my layout was set to US (normally DE) uninstalling xf86-input-evdev fixed it.

not sure why .. that driver seems to get loaded even if you use the normal keyboard driver.

This is a consequence of adding the input hotplug support - it ignores all your input device settings in xorg.conf, and expects you to configure them via HAL .fdi files.

I've e-mailed Pat and asked him to disable it by default (since it requires more configuration work from the end-user than I expected, and isn't very well documented yet - it will hopefully instead be available as an optional extra you can enable if you want to experiment with it).

For completeness sake - if you do actually want to use input hotplugging, you must:

A) Set the right locale in /usr/share/hal/fdi/policy/10osvendor if you are not using a US layout.

B) Make sure your window manager is not trying to override the keymap layout - either tell it not to set a keymap, or tell it to explicitly use evdev (if you set pc104 in your window manager, strange key remappings happen with evdev).

ah cool ... that explains it

Yes, this input hotplugging is quite annoying.

At first, some of my keyboard shortcuts didn't work unless I went into Xfce's settings manager and changed (or at least acted like I was going to change) one of them, and then they were fine until X was restarted.

Then I decided to futz with the /usr/share/hal/fdi/policy/10osvendor/10-x11-input.fdi file (copy it to /etc/hal/fdi/policy/ and do the edits there) and that made it worse - no keyboard input was accepted at all. Of course, that means my edits were bad, but still, you get the idea

PiterPunk is also looking into this, and it seems that it's not an issue except on en_US layouts, but that might not be completely accurate either. Anyway, blacklisting the evdev module avoids the problem altogether here until a better fix is found, and it's being looked at to try and find the best way to handle it. Note that you'll have to reboot after adding the evdev module to the blacklist (either edit /etc/modprobe.d/blacklist, or create /etc/modprobe.d/evdev with one line that reads "blacklist evdev" - this is what I did, so it will be easier to see the custom change later).

rworkman:

Are you certain? Because the solution of just removing 10-x11-input.fdi works fine for both Debian & Ubuntu, who implemented it to disable input hotplugging by default.

Blacklisting evdev is, IMHO, overkill.

You could also try removing 10-keymap.fdi, since that also tries to call evdev and override the X layout.

Well, no, I'm not certain. I was trying to debug this a bit before all of this information was gathered in one place, so I was piecing together bits from various places trying to get a workable solution. I know I removed the 10-x11-input.fdi file from /usr/share, but now that I think a bit more about it, I just might have had a custom one in /etc/hal, and since the custom one obviously had other issues, that just might have been the problem. I'll try this again later tonight once my daughter drifts off to sleep and I have a bit of free time. I'd certainly like for it to work, as I completely agree that blacklisting evdev is not a good solution at all - too much other stuff depends on it.

Okay, yeah, removing the file (and not leaving a stray replica in /etc/hal) results in things working properly.

A decision has been made about how this will be fixed in -current, but I'll wait until Pat syncs the changes publicly to say more

rworkman:

Pat's posted the 'fix' (disabling HAL and D-Bus in xorg-server again), but to be honest, I'm a little disappointed; the solution is the worst of the three - blacklisting evdev or just removing a single file from HAL are far preferable to this (since neither of those require recompiling to enable input hotplugging).

Also, Pat's explanation is a bit odd - "Evidently, the HAL/D-Bus enabled X server, xf86-input-evdev, and one of HAL's .fdi files aren't playing well together."

AFAICT, they are all working fine and doing what they are supposed to do - the problem is just that the input hotplug is a bit immature, and most people aren't aware of how it works, and it is somewhat difficult to configure at the moment, so this line really doesn't sit well with me.

Oh..God! I spent too many hours trying to find an "elegant" way to do this on PCLinuxOS...and I think I've lost my sanity!! I have a multiseat setup...so I can't get rid of evdev (you need it for multiple independent inputs), but I can't exactly keep it when it borks the system in single-seat mode!

Eventually I just modified my /etc/init.d/dm to rmmod and modprobe evdev as required by the situation...meaning this multiseat setup has yet one more quirk (in addition to the other zillions like not being able to switch user on any but the first seat): no joysticks, etc... in single seat mode!

Ha ha ha ha ha ha ha ha ha ha ha!!! Bwaaaahahahahahahahaha!!! HAAAAA HAAAA HAAA HAAA HAAA HAAA HAA HAAA!!!! Oh God - this "hotplaguing" being crammed down everyone's throat is enough to make you jump ship and go back to using Windows where you expect that sort of thing! BWAAAAAAHAHAHAHAHAHAHAHA HA HA HA HA!! I think I'm tearing up from maniacal laughter here...