I've been using kernel-2.6.25.4-30.fc9 from updates-testing, and I've noticed several weird keyboard-related problems: 1. When booting this kernel on my Dell Latitude D620 laptop, the "Fn" (function) key is inverted: it's active *unless* I'm holding it down. (This was preventing me from entering my LUKS passphrase, because the Fn key turns a cluster of keys into numeric keypad keys.) 2. Also on my Dell Latitude D620 laptop, when I resume from a suspend, the keyboard is non-functional. (The system is otherwise fine, but the only way I've found to reset the keyboard is to reboot.) 3. I have several system with a "Chicony Saitek Eclipse Keyboard" (native USB keyboards connected via USB). In X, the numeric keyboard is completely whacked out, regardless of the Num_Lock state. (Xev shows that some keys are sending the correct keycodes and some aren't, but even the keys that are sending the right keycodes don't work.) Reverting to kernel-2.6.25.3-18.fc9 makes all of these problems go away. HTH...
Correction: problem #3 appears to be some sort of X-related weirdness, not the fault of the kernel. (The numeric keypad doesn't work, regardless of the kernel. It's probably been broken since the F9 test releases, but I never noticed because I was using my laptop to test F9, and thus didn't have a USB keyboard with a numeric keypad.) Problems #1 and #2, however, definitely go away when I revert from 2.6.25.4-30 to 2.6.25.3-18.
The Function key state inversion at boot is still present in 2.6.25.6-55. Issue #2 might also be an X-related problem, as I'm having difficulty reproducing it now. But issue #1 is definitely a kernel-related problem, as the keyboard works correctly in GRUB for all kernels, but only post- 2.6.25.4-30 kernels invert the Function key during boot.
(In reply to comment #0) > I've been using kernel-2.6.25.4-30.fc9 from updates-testing, and I've noticed > several weird keyboard-related problems: > > 1. When booting this kernel on my Dell Latitude D620 laptop, the "Fn" (function) > key is inverted: it's active *unless* I'm holding it down. (This was preventing > me from entering my LUKS passphrase, because the Fn key turns a cluster of keys > into numeric keypad keys.) > Does that apply to all of the keys affected by Fn or just the numeric ones? There are no changes in this area that I can see other than one small change in 2.6.25.4. Can you try booting the new kernel with this extra parameter: vt.default_utf8=0
Keys other than the numeric ones are affected. If I boot 2.6.25.6-55 with vt.default_utf8=0, after the kernel prints: Loading keymap. Loading /lib/kbd/keymaps/i386/qwerty/us.map The kernel then also prints: loadkeys: warning: this map uses Unicode symbols (perhaps you want to do `kbd_mode -u'?) However, the Function key inversion does *not* happen; the keys work correctly. (Unfortunately, 2.6.25.6-55 is still unusable due to bug 451399, but that's another issue...)
I haven't needed to use vt.default_utf8=0 on recent kernels, including the Rawhide kernels. Unless you want to hold this bug open for tracking purposes, feel free to close with CURRENTRELEASE.