This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1025041 - Bad Keycode for Backtick/Tilde key on MacBookAir6,2
Bad Keycode for Backtick/Tilde key on MacBookAir6,2
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
20
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-30 15:43 EDT by Alex Markley
Modified: 2015-07-17 08:37 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-12-10 10:01:19 EST
Type: Bug
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 Alex Markley 2013-10-30 15:43:04 EDT
Description of problem:

On my MacBookAir6,2, the backtick / tilde key on the keyboard produces < and > symbols instead of the expected ` and ~ symbols.


Version-Release number of selected component (if applicable):

kernel-3.11.6-200.fc19.x86_64


How reproducible:

Completely reproducible.


Steps to Reproduce:

1. Press backtick / tilde key.


Actual results:

< and > symbols are produced.


Expected results:

` and ~ symbols.

Additional info:

My keyboard layout is default for US.

This problem is present at the console also, so it's not an Xorg issue. However, here's the xev output for reference:

KeyPress event, serial 36, synthetic NO, window 0x1e00001,
    root 0x9f, subw 0x0, time 17299565, (869,408), root:(870,499),
    state 0x0, keycode 94 (keysym 0x3c, less), same_screen YES,
    XLookupString gives 1 bytes: (3c) "<"
    XmbLookupString gives 1 bytes: (3c) "<"
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x1e00001,
    root 0x9f, subw 0x0, time 17299637, (869,408), root:(870,499),
    state 0x0, keycode 94 (keysym 0x3c, less), same_screen YES,
    XLookupString gives 1 bytes: (3c) "<"
    XFilterEvent returns: False

You'll notice that the keycode is given as 94. Based on my comparisons with other systems, the keycode SHOULD be 49.

I can work around this with xmodmap; however, this does not allow me to type any backtick or tilde characters at the console or at the user login screen.

Please let me know if I can provide any other information.
Comment 1 Justin M. Forbes 2014-01-03 17:09:15 EST
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs.

Fedora 19 has now been rebased to 3.12.6-200.fc19.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 20, and are still experiencing this issue, please change the version to Fedora 20.

If you experience different issues, please open a new bug report for those.
Comment 2 Alex Markley 2014-01-28 13:31:49 EST
Fedora 20 still exhibits this bug on MacBookAir6,2. According to an upstream bug report, the ANSI/ISO detection of the keyboard is incorrect.

        https://bugzilla.kernel.org/show_bug.cgi?id=60181#c43

My current workaround is to place this in rc.local:

        echo 0 > /sys/module/hid_apple/parameters/iso_layout

That fixes the problem.
Comment 3 Justin M. Forbes 2014-03-17 14:42:39 EDT
*********** MASS BUG UPDATE **************

This bug has been in a needinfo state for several weeks and is being closed with insufficient data due to inactivity. If this is still an issue with Fedora 20, please feel free to reopen the bug and provide the additional information requested.
Comment 4 Emmanuele Bassi 2014-05-22 13:14:55 EDT
can we please reopen this bug? the bug hasn't been resolved.
Comment 5 Justin M. Forbes 2014-12-10 10:01:19 EST
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in over 3 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.
Comment 6 Emmanuele Bassi 2015-07-17 08:37:39 EDT
You can keep closing this bug for "insufficient data", but comment #2 provides that data as well as a workaround.

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