Bug 450158 - keyboard problems with kernel-2.6.25.4-30.fc9
keyboard problems with kernel-2.6.25.4-30.fc9
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-05 12:10 EDT by James Ralston
Modified: 2008-10-24 00:44 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-10-24 00:44:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description James Ralston 2008-06-05 12:10:43 EDT
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...
Comment 1 James Ralston 2008-06-11 17:43:45 EDT
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.
Comment 2 James Ralston 2008-06-13 17:44:48 EDT
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.
Comment 3 Chuck Ebbert 2008-06-14 02:27:42 EDT
(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

Comment 4 James Ralston 2008-06-17 20:44:44 EDT
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...)
Comment 5 James Ralston 2008-09-18 13:52:54 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.