Bug 450158

Summary:	keyboard problems with kernel-2.6.25.4-30.fc9
Product:	[Fedora] Fedora	Reporter:	James Ralston <ralston>
Component:	kernel	Assignee:	Kernel Maintainer List <kernel-maint>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	low	Docs Contact:
Priority:	low
Version:	9
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-10-24 04:44:56 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description James Ralston 2008-06-05 16:10:43 UTC

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 21:43:45 UTC

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 21:44:48 UTC

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 06:27:42 UTC

(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-18 00:44:44 UTC

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 17:52:54 UTC

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.