Bug 598001 - Keystroke Fn+F4 erroneously recognized as 'p' on a HP laptop
Keystroke Fn+F4 erroneously recognized as 'p' on a HP laptop
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
14
All Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-31 04:50 EDT by Tadej Janež
Modified: 2011-08-31 05:40 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-08-31 05:40:29 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 Tadej Janež 2010-05-31 04:50:45 EDT
Description of problem:
I have an HP EliteBook 8530p laptop with an up2date F13. The system erroneously recognizes key stroke F4 as key "p".

This is really annoying as I use Fn+F4 key combination for external monitor switching (see bug #576114).

Version-Release number of selected component (if applicable):
kernel-PAE-2.6.33.4-95.fc13.i686
xorg-x11-server-common-1.8.0-12.fc13.i686

How reproducible:
Always.

Additional info:
Here is xev output after pressing F4 and "p":
KeyPress event, serial 32, synthetic NO, window 0x4e00001,
    root 0x10c, subw 0x0, time 6121185, (1247,146), root:(1251,227),
    state 0x0, keycode 33 (keysym 0x70, p), same_screen YES,
    XLookupString gives 1 bytes: (70) "p"
    XmbLookupString gives 1 bytes: (70) "p"
    XFilterEvent returns: False

KeyRelease event, serial 32, synthetic NO, window 0x4e00001,
    root 0x10c, subw 0x0, time 6121238, (1247,146), root:(1251,227),
    state 0x0, keycode 33 (keysym 0x70, p), same_screen YES,
    XLookupString gives 1 bytes: (70) "p"
    XFilterEvent returns: False

KeyPress event, serial 32, synthetic NO, window 0x4e00001,
    root 0x10c, subw 0x0, time 6128961, (1247,146), root:(1251,227),
    state 0x0, keycode 33 (keysym 0x70, p), same_screen YES,
    XLookupString gives 1 bytes: (70) "p"
    XmbLookupString gives 1 bytes: (70) "p"
    XFilterEvent returns: False

KeyRelease event, serial 32, synthetic NO, window 0x4e00001,
    root 0x10c, subw 0x0, time 6129012, (1247,146), root:(1251,227),
    state 0x0, keycode 33 (keysym 0x70, p), same_screen YES,
    XLookupString gives 1 bytes: (70) "p"
    XFilterEvent returns: False
Comment 1 Tadej Janež 2010-05-31 04:52:46 EDT
Just one more thing to avoid any confusions, the above output of xev after pressing F4 and "p" really is identical!
Comment 2 Tadej Janež 2010-06-02 04:43:55 EDT
I have to make a correction to the bug report.

I can't reproduce the above anymore, however, what happens now is that pressing Fn+F4 results in a key stroke "p". Pressing just F4 results in a normal F4 key stroke.

Another thing. Using F12 with kernel-2.6.31.5-127.fc12.i686 on the same laptop, I can't reproduce this problem. So it seems this regression was introduced somewhere between.

Hope this helps in resolving this issue!
Comment 3 Tadej Janež 2010-11-25 03:56:07 EST
I have tried the LiveUSB version of F14 on the same laptop and the issue remains.

Version-Release number of selected component (if applicable):
kernel-2.6.35.6-45.fc14.i686
xorg-x11-server-common-1.9.0-15.fc14.i686

This is quite annoying... does anyone have any clue on what causes this weird behaviour?
Comment 4 Tadej Janež 2011-01-21 17:04:50 EST
I've had the opportunity to try Fn+F4 key combination on another HP laptop and it has the same bug. Model number is EliteBook 8540p.
Comment 5 Tadej Janež 2011-08-31 05:40:29 EDT
I can't reproduce the bug on an up2date F-15, so I'm closing it.

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